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 demeure disponible pour d'autres processus.
L1 fournit un cache de courte durée (une seconde) 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. D'autres limites s'appliquent également.
Consultez 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
Dans la section suivante, nous expliquons comment Apigee gère les entrées de cache lorsque 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) :
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.
Apigee écrit également l'entrée dans le cache L2.
Lorsqu'une règle lit à partir du cache (règle LookupCache ou ResponseCache) :
Apigee recherche d'abord l'entrée dans le cache en mémoire L1 du processeur de messages qui traite la requête.
S'il n'y a pas d'entrée en mémoire correspondante, Apigee recherche l'entrée dans le cache persistant L2.
Si l'entrée ne se trouve pas dans le cache persistant :
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.
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.
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.
Comme L1 est configuré pour expirer en 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 par le biais 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, concernant 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. Elles 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 qui n'ont pas été utilisées depuis le plus longtemps. Les entrées évincées de la mémoire restent dans le cache L2 jusqu'à leur expiration ou leur invalidation.
Cache persistant (L2) : les entrées évincées du cache en mémoire restent dans le cache persistant en fonction des paramètres de valeur TTL (Time To Live) configurables.
Optimisations configurables
Le tableau suivant liste les paramètres que vous pouvez utiliser pour optimiser les performances du cache.
Paramètre
Description
Notes
Expiration
Spécifie la valeur TTL des entrées de cache.
Aucun
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/27 (UTC)."],[[["\u003cp\u003eThis documentation covers the caching mechanisms for Apigee and Apigee hybrid, focusing on how caching policies interact with the underlying cache system.\u003c/p\u003e\n"],["\u003cp\u003eApigee uses a two-level cache system, including a short-lived, in-memory L1 cache for rapid access and a persistent L2 cache for storing entries beyond L1's lifespan.\u003c/p\u003e\n"],["\u003cp\u003eCache policies, such as PopulateCache, LookupCache, InvalidateCache, and ResponseCache, interact with both L1 and L2 caches to write, read, update, and invalidate entries.\u003c/p\u003e\n"],["\u003cp\u003eWhen a cache entry is written, it is stored in both L1 and L2, and when read, Apigee first checks L1, then L2 if not found, while updates or invalidations remove the entry from both levels.\u003c/p\u003e\n"],["\u003cp\u003eWhile L1 memory limits are managed by Apigee, the persistent L2 cache retains evicted entries until expiration, and configurable settings like expiration times can be adjusted to optimize cache performance.\u003c/p\u003e\n"]]],[],null,["# Cache internals\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nThis topic describes the workings of the cache beneath policies such as the\n[PopulateCache policy](/apigee/docs/api-platform/reference/policies/populate-cache-policy), [LookupCache policy](/apigee/docs/api-platform/reference/policies/lookup-cache-policy), [InvalidateCache policy](/apigee/docs/api-platform/reference/policies/invalidate-cache-policy), and\n[ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy).\n\nAbout caches\n------------\n\nWhen a caching policy executes, a short-lived, L1 cache\nis created. After one second, if a cached item is not accessed, it is persisted in a database\nwhere it is available to all message processors deployed in an environment until the cache expires.\nYou configure the expiration time directly in the cache policy.\n| **Note:** [List](https://cloud.google.com/apigee/docs/reference/apis/apigee/rest/v1/organizations.environments.caches/list) and [delete](https://cloud.google.com/apigee/docs/reference/apis/apigee/rest/v1/organizations.environments.caches/delete) are the only cache API operations available.\n\nIn-memory and persistent cache levels\n-------------------------------------\n\nBoth the shared and environment caches are built on a two-level system made up of an in-memory\nlevel and a persistent level as shown in the following figure. Policies interact with both levels\nas a combined framework. Apigee manages the relationship between the levels.\n| **Note:** For more information on the cache policies, see: [PopulateCache](/apigee/docs/api-platform/reference/policies/populate-cache-policy), [LookupCache](/apigee/docs/api-platform/reference/policies/lookup-cache-policy), [InvalidateCache](/apigee/docs/api-platform/reference/policies/invalidate-cache-policy), and [ResponseCache](/apigee/docs/api-platform/reference/policies/response-cache-policy).\n\n- **Level 1 is an in-memory cache (L1)** for fast access. Each message processing (MP) node has its own in-memory cache for the fastest response to requests.\n - L1 is a short-lived (1 second), in-memory cache.\n - As the memory limit is reached, Apigee removes cache entries from memory (although they are still kept in the L2 persistent cache) to ensure that memory remains available for other processes.\n - L1 is provided with short-lived one-second cache to perform faster lookups for concurrent requests with the same cache key.\n- **Level 2 is a persistent cache (L2)** beneath the in-memory cache. All message processing nodes share a cache data store (Cassandra) for persisting cache entries.\n - Cache entries persist here even after they are removed from L1 cache, such as when in-memory limits are reached.\n - Because the persistent cache is shared across message processors (even in different regions), cache entries are available regardless of which node receives a request for the cached data.\n - Only entries of a certain size may be cached, and other cache limits apply. See [Managing cache limits](#cachelimits).\n - The cache content in L2 is encrypted with the AES-256 algorithm. Data is decrypted before being used by the runtime and is encrypted before being written into L2. So the encryption process is invisible to users.\n\nHow policies use the cache\n--------------------------\n\nThe following describes how Apigee handles cache entries as your caching policies do\ntheir work.\n\n- When a policy **writes a new entry** to the cache (PopulateCache or ResponseCache policy):\n 1. Apigee writes the entry to the in-memory L1 cache on only the message processor that handled the request. If the memory limits on the message processor are reached before the entry expires, then Apigee removes the entry from L1 cache.\n 2. Apigee also writes the entry to L2 cache.\n- When a policy **reads** from the cache (LookupCache or ResponseCache policy):\n 1. Apigee looks first for the entry in the in-memory L1 cache of the message processor handling the request.\n 2. If there is no corresponding in-memory entry, Apigee looks for the entry in the L2 persistent cache.\n 3. If the entry is not in the persistent cache:\n - [LookupCache policy](/apigee/docs/api-platform/reference/policies/lookup-cache-policy): No value is retrieved from the cache.\n - [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy): Apigee returns the actual response from the target to the client and stores the entry in cache until it expires or is invalidated.\n- When a policy **updates** or **invalidates** an existing cache entry ([InvalidateCache policy](/apigee/docs/api-platform/reference/policies/invalidate-cache-policy), [PopulateCache policy](/apigee/docs/api-platform/reference/policies/populate-cache-policy), or [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy)):\n 1. The message processor receiving the request deletes the entry from the one-second in-memory L1 cache and also deletes the entry from the L2 cache.\n 2. After an update or invalidation, it is possible that the other message processors will still hold onto the in-memory L1 cache.\n 3. Since L1 is configured to expire in one second, there is no delete/update event needed to remove the entry from L1.\n\nManaging cache limits\n---------------------\n\nThrough configuration, you can manage some aspects of the cache. The overall space\navailable for in-memory cache is limited by system resources and is not configurable.\nThe following constraints apply to cache:\n\n- **Cache limits** : [Various cache limits](/apigee/docs/api-platform/reference/limits) apply, such as name and value size, total number of caches, the number of items in a cache, and expiration.\n- **In-memory (L1) cache.** Memory limits for your cache are not configurable. Limits are set by Apigee for each message processor that hosts caches for multiple customers.\n\n In a hosted cloud environment, where in-memory caches for all customer deployments are hosted\n across multiple shared message processors, each processor features an Apigee-configurable\n memory percentage threshold to ensure that caching does not consume all of the application's\n memory. As the threshold is crossed for a given message processor, cache entries are evicted\n from memory on a least-recently-used basis. Entries evicted from memory remain in L2 cache\n until they expire or are invalidated.\n- **Persistent (L2) cache.** Entries evicted from the in-memory cache remain in the persistent cache according to configurable time-to-live settings.\n\nConfigurable optimizations\n--------------------------\n\nThe following table lists settings you can use to optimize cache performance."]]
