Cuando se ejecuta una política de almacenamiento en caché, se crea una caché de nivel 1 de corta duración. Si no se accede a un elemento almacenado en caché en un segundo, se conserva en una base de datos donde está disponible para todos los procesadores de mensajes implementados en un entorno hasta que caduca la caché.
El tiempo de caducidad se configura directamente en la política de caché.
Niveles de caché persistente y en memoria
Tanto la caché compartida como la de entorno se basan en un sistema de dos niveles formado por un nivel en memoria y un nivel persistente, como se muestra en la siguiente figura. Las políticas interactúan con ambos niveles
como un marco combinado. Apigee gestiona la relación entre los niveles.
El nivel 1 es una caché en memoria (L1) para acceder rápidamente. Cada nodo de procesamiento de mensajes (MP) tiene su propia caché en memoria para responder a las solicitudes lo más rápido posible.
L1 es una caché en memoria de corta duración (1 segundo).
Cuando se alcanza el límite de memoria, Apigee elimina las entradas de caché de la memoria (aunque se conservan en la caché persistente de nivel 2) para asegurarse de que la memoria siga estando disponible para otros procesos.
L1 cuenta con una caché de un segundo de duración para realizar búsquedas más rápidas de solicitudes simultáneas con la misma clave de caché.
El nivel 2 es una caché persistente (L2) que se encuentra debajo de la caché en memoria. Todos los nodos de procesamiento de mensajes comparten un almacén de datos de caché (Cassandra) para conservar las entradas de caché.
Las entradas de la caché permanecen aquí incluso después de que se hayan eliminado de la caché de nivel 1, por ejemplo, cuando se alcanzan los límites de memoria.
Como la caché persistente se comparte entre los procesadores de mensajes (incluso en regiones diferentes), las entradas de caché están disponibles independientemente del nodo que reciba una solicitud de los datos almacenados en caché.
Solo se pueden almacenar en caché las entradas de un tamaño determinado y se aplican otros límites de caché.
Consulta Gestionar los límites de la caché.
El contenido de la caché de nivel 2 se cifra con el algoritmo AES-256.
Los datos se descifran antes de que el tiempo de ejecución los utilice y se cifran antes de escribirse en la caché de nivel 2. Por lo tanto, el proceso de cifrado es invisible para los usuarios.
Cómo usan las políticas la caché
A continuación se describe cómo gestiona Apigee las entradas de caché a medida que las políticas de almacenamiento en caché hacen su trabajo.
Cuando una política escribe una nueva entrada en la caché (política PopulateCache o ResponseCache):
Apigee escribe la entrada en la caché L1 en memoria solo en el procesador de mensajes que ha gestionado la solicitud. Si se alcanzan los límites de memoria del procesador de mensajes antes de que caduque la entrada, Apigee eliminará la entrada de la caché de nivel 1.
Apigee también escribe la entrada en la caché de nivel 2.
Cuando una política lee de la caché (política LookupCache o ResponseCache):
Apigee busca primero la entrada en la caché L1 en memoria del procesador de mensajes
que gestiona la solicitud.
Si no hay ninguna entrada en memoria correspondiente, Apigee busca la entrada en la caché persistente de nivel 2.
El procesador de mensajes que recibe la solicitud elimina la entrada de la caché L1 en memoria de un segundo y también la elimina de la caché L2.
Después de una actualización o invalidación, es posible que los demás procesadores de mensajes sigan conservando la caché de nivel 1 en la memoria.
Como L1 está configurada para caducar en un segundo, no es necesario ningún evento de eliminación o actualización para quitar la entrada de L1.
Gestionar los límites de la caché
Mediante la configuración, puede gestionar algunos aspectos de la caché. El espacio total disponible para la caché en memoria está limitado por los recursos del sistema y no se puede configurar.
Se aplican las siguientes restricciones a la caché:
Límites de la caché: se aplican varios límites de la caché
, como el tamaño del nombre y del valor, el número total de cachés, el número de elementos de una caché
y la caducidad.
Caché en memoria (L1). Los límites de memoria de tu caché no se pueden configurar. Apigee establece límites para cada procesador de mensajes que aloja cachés de varios clientes.
En un entorno de nube alojado, donde las cachés en memoria de todas las implementaciones de los clientes se alojan en varios procesadores de mensajes compartidos, cada procesador incluye un umbral de porcentaje de memoria configurable por Apigee para asegurarse de que el almacenamiento en caché no consuma toda la memoria de la aplicación. Cuando se supera el umbral de un procesador de mensajes determinado, las entradas de la caché se eliminan de la memoria según el criterio de uso menos reciente. Las entradas expulsadas de la memoria permanecen en la caché de nivel 2
hasta que caducan o se invalidan.
Caché persistente (L2). Las entradas expulsadas de la caché en memoria
permanecen en la caché persistente según los ajustes de tiempo de vida configurables.
Optimizaciones configurables
En la siguiente tabla se indican los ajustes que puede usar para optimizar el rendimiento de la caché.
Ajuste
Descripción
Notas
Caducidad
Especifica el tiempo de vida de las entradas de la caché.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (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."]]
