Composants internes du cache

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Cette rubrique décrit le fonctionnement du cache selon les règles telles PopulateCache, LookupCache, InvalidateCache et ResponseCache.

À propos des caches

Lorsqu'une règle de mise en cache s'exécute, un cache L1 de courte durée est créé. Au bout d'une seconde sans accès à un élément mis en cache, celui-ci est conservé dans une base de données où il est disponible pour tous les processeurs de messages déployés dans un environnement, jusqu'à l'expiration du cache. Vous configurez le délai d'expiration directement dans la règle de cache.

Niveaux de cache en mémoire et de cache persistant

Les caches partagés et d'environnement sont basés sur un système à deux niveaux constitué d'un niveau en mémoire et d'un niveau persistant, comme illustré dans la figure suivante. Les règles interagissent avec ces deux niveaux sous forme de framework combiné. Apigee gère la relation entre ces niveaux.

• Le niveau 1 est un cache en mémoire (L1) permettant un accès rapide. Chaque nœud de processeur de messages dispose de son propre cache en mémoire, afin de répondre rapidement aux requêtes.
  • L1 est un cache en mémoire de courte durée (1 seconde).
  • Lorsque la limite de mémoire est atteinte, Apigee supprime les entrées de cache de la mémoire (bien qu'elles restent conservées dans le cache persistant L2) pour garantir que la mémoire reste disponible pour d'autres processus.
  • L1 est fourni avec un cache d'une seconde de courte durée afin de permettre des recherches plus rapides pour les requêtes simultanées portant la même clé de cache.
• Le niveau 2 est un cache persistant (L2) sous le cache en mémoire. Tous les nœuds de traitement de messages partagent un datastore de mise en cache (Cassandra) pour conserver des entrées de cache.
  • Les entrées de cache sont conservées ici même après leur suppression du cache L1, par exemple lorsque les limites en mémoire sont atteintes.
  • Comme le cache persistant est partagé entre les processeurs de messages (même dans différentes régions), les entrées de cache sont disponibles quel que soit le nœud recevant une requête pour les données mises en cache.
  • Seules les entrées d'une certaine taille peuvent être mises en cache, et d'autres limites s'appliquent. Consultez la section Gérer les limites de cache.
  • Le contenu du cache dans le niveau L2 est chiffré avec l'algorithme AES-256. Les données sont déchiffrées avant leur utilisation par l'environnement d'exécution, et sont chiffrées avant d'être écrites dans le cache L2. Le processus de chiffrement est donc invisible pour les utilisateurs.

Comment les règles utilisent le cache

La section suivante explique comment Apigee gère les entrées de cache pendant que vos règles de mise en cache s'appliquent.

• Lorsqu'une règle écrit une nouvelle entrée dans le cache (règle PopulateCache ou ResponseCache) :
  1. Apigee écrit l'entrée dans le cache L1 en mémoire uniquement sur le processeur de messages qui a traité la requête. Si les limites de mémoire du processeur de messages sont atteintes avant l'expiration de l'entrée, Apigee supprime l'entrée du cache L1.
  2. Apigee écrit également l'entrée dans le cache L2.
• Lorsqu'une règle lit à partir du cache (règle LookupCache ou ResponseCache) :
  1. Apigee recherche d'abord l'entrée dans le cache L1 en mémoire du processeur de messages qui traite la requête.
  2. S'il n'y a pas d'entrée en mémoire correspondante, Apigee recherche l'entrée dans le cache persistant L2.
  3. Si l'entrée ne se trouve pas dans le cache persistant :
     • Règle LookupCache : aucune valeur n'est extraite du cache.
     • Règle ResponseCache : Apigee renvoie la réponse réelle de la cible au client et stocke l'entrée dans le cache jusqu'à son expiration ou son invalidation.
• Lorsqu'une règle met à jour ou invalide une entrée de cache existante (règle InvalidateCache, PopulateCache ou ResponseCache) :
  1. Le processeur de messages recevant la requête supprime l'entrée du cache en mémoire L1 d'une seconde et supprime également l'entrée du cache L2.
  2. Après une mise à jour ou une invalidation, il est possible que les autres processeurs de messages conservent toujours le cache en mémoire L1.
  3. Comme L1 est configuré pour expirer dans une seconde, aucun événement de suppression/mise à jour n'est nécessaire pour supprimer l'entrée de L1.

Gérer les limites de cache

Vous pouvez gérer certains aspects du cache via des configurations. L'espace global disponible pour la mise en cache en mémoire est limité par les ressources système et n'est pas configurable. Les contraintes suivantes s'appliquent au cache :

• Limites de cache : des limites de cache diverses s'appliquent, telles que la taille du nom et des valeurs, le nombre total de caches, le nombre d'éléments dans un cache et l'expiration.
• Cache en mémoire (L1) : les limites de mémoire de votre cache ne sont pas configurables. Les limites sont définies par Apigee pour chaque processeur de messages qui héberge des caches pour plusieurs clients.

  Dans un environnement cloud hébergé, dans lequel les caches en mémoire de tous les déploiements du client sont hébergés sur plusieurs processeurs de messages partagés, chaque processeur dispose d'un seuil de pourcentage de mémoire configurable sur Apigee pour garantir que la mise en cache ne consomme pas toute la mémoire de l'application. Lorsque le seuil est dépassé pour un processeur de messages donné, les entrées de cache sont évincées de la mémoire, en commençant par celles les moins récemment utilisées. Les entrées supprimées de la mémoire restent dans le cache L2 jusqu'à leur expiration ou leur invalidation.

• Cache persistant (L2) : les entrées supprimées du cache en mémoire restent dans le cache persistant en fonction des paramètres de durée de vie configurables.

Optimisations configurables

Le tableau suivant répertorie les paramètres que vous pouvez utiliser pour optimiser les performances du cache. 

Paramètre	Description	Notes
Expiration	Spécifie la durée de vie des entrées de cache.	Aucun