Quando viene eseguita una policy di memorizzazione nella cache, viene creata una cache L1 di breve durata. Dopo un secondo, se non viene eseguito l'accesso a un elemento memorizzato nella cache, questo viene reso persistente in un database
dove è disponibile per tutti i processori di messaggi distribuiti in un ambiente fino alla scadenza della cache.
Configura il tempo di scadenza direttamente nella policy della cache.
Livelli di cache in memoria e persistente
Entrambe le cache condivise e dell'ambiente sono basate su un sistema a due livelli costituito da un livello in memoria
e da un livello persistente, come mostrato nella figura seguente. I criteri interagiscono con entrambi i livelli
come un framework combinato. Apigee gestisce la relazione tra i livelli.
Il livello 1 è una cache in memoria (L1) per un accesso rapido. Ogni nodo di elaborazione dei messaggi (MP)
ha una propria cache in memoria per rispondere più rapidamente alle richieste.
L1 è una cache in memoria di breve durata (1 secondo).
Quando viene raggiunto il limite di memoria, Apigee rimuove le voci della cache dalla memoria (anche se
vengono comunque conservate nella cache persistente di livello 2) per garantire che la memoria rimanga disponibile
per altri processi.
L1 viene fornito con una cache di un secondo di breve durata per eseguire ricerche più rapide per
richieste simultanee con la stessa chiave di cache.
Il livello 2 è una cache persistente (L2) sotto la cache in memoria. Tutti i nodi di elaborazione dei messaggi
condividono un datastore della cache (Cassandra) per rendere persistenti le voci della cache.
Le voci della cache vengono mantenute qui anche dopo essere state rimosse dalla cache L1, ad esempio quando
vengono raggiunti i limiti in memoria.
Poiché la cache persistente è condivisa tra i processori di messaggi (anche in regioni diverse), le voci della cache sono disponibili indipendentemente dal nodo che riceve una richiesta per i dati memorizzati nella cache.
Solo le voci di una determinata dimensione possono essere memorizzate nella cache e si applicano altri limiti della cache.
Vedi Gestire i limiti della cache.
I contenuti della cache di livello 2 sono criptati con l'algoritmo AES-256.
I dati vengono decriptati prima di essere utilizzati dal runtime e vengono
criptati prima di essere scritti nel livello 2. Pertanto, il processo di crittografia è invisibile agli utenti.
Come le norme utilizzano la cache
Di seguito viene descritto il modo in cui Apigee gestisce le voci della cache man mano che le tue norme di memorizzazione nella cache
svolgono il loro lavoro.
Quando una norma scrive una nuova voce nella cache (norma PopulateCache o
ResponseCache):
Apigee scrive la voce nella cache L1 in memoria solo sul processore di messaggi
che ha gestito la richiesta. Se i limiti di memoria del processore di messaggi vengono raggiunti
prima della scadenza della voce, Apigee rimuove la voce dalla cache L1.
Apigee scrive anche la voce nella cache L2.
Quando una policy legge dalla cache (policy LookupCache o ResponseCache):
Apigee cerca prima la voce nella cache L1 in memoria del processore di messaggi
che gestisce la richiesta.
Se non è presente alcuna voce corrispondente in memoria, Apigee cerca la voce nella cache persistente L2.
Policy ResponseCache: Apigee restituisce la risposta effettiva dalla destinazione al
client e memorizza la voce nella cache fino alla scadenza o all'invalidazione.
Il processore di messaggi che riceve la richiesta elimina la voce dalla cache L1 in memoria di un secondo ed elimina anche la voce dalla cache L2.
Dopo un aggiornamento o un'invalidazione, è possibile che gli altri processori di messaggi
mantengano ancora la cache L1 in memoria.
Poiché L1 è configurato per scadere in un secondo, non è necessario alcun evento di eliminazione/aggiornamento
per rimuovere la voce da L1.
Gestione dei limiti della cache
Tramite la configurazione, puoi gestire alcuni aspetti della cache. Lo spazio totale
disponibile per la cache in memoria è limitato dalle risorse di sistema e non è configurabile.
Si applicano i seguenti vincoli alla cache:
Limiti della cache: si applicano vari limiti della cache, ad esempio dimensioni del nome e del valore, numero totale di cache, numero di elementi in una cache ed scadenza.
Cache in memoria (L1). I limiti di memoria per la cache non sono configurabili. I limiti sono
impostati da Apigee per ogni processore di messaggi che ospita cache per più clienti.
In un ambiente cloud ospitato, in cui le cache in memoria per tutte le implementazioni dei clienti sono ospitate
in più processori di messaggi condivisi, ogni processore dispone di una soglia di percentuale di memoria configurabile da Apigee
per garantire che la memorizzazione nella cache non consumi tutta la memoria dell'applicazione. Quando viene superata la soglia per un determinato processore di messaggi, le voci della cache vengono eliminate
dalla memoria in base al criterio di utilizzo meno recente. Le voci rimosse dalla memoria rimangono nella cache L2
finché non scadono o vengono invalidate.
Cache persistente (L2). Le voci rimosse dalla cache in memoria
rimangono nella cache permanente in base alle impostazioni di durata configurabili.
Ottimizzazioni configurabili
La seguente tabella elenca le impostazioni che puoi utilizzare per ottimizzare le prestazioni della cache.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 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."]]