Bei der Ausführung einer Caching-Richtlinie wird ein kurzlebiger L1-Cache erstellt. Wenn nach einer Sekunde nicht auf ein im Cache gespeichertes Element zugegriffen wird, wird es in einer Datenbank gespeichert, wo es für alle in einer Umgebung bereitgestellten Nachrichtenprozessoren verfügbar ist, bis der Cache abläuft.
Die Ablaufzeit konfigurieren Sie direkt in der Cache-Richtlinie.
In-Memory- und nichtflüchtige Cache-Ebenen
Die gemeinsam genutzten und Umgebungs-Caches basieren auf einem System auf zwei Ebenen, das aus einer speicherinternen Ebene und einem nichtflüchtigen Speicher besteht, wie in der folgenden Abbildung dargestellt. Richtlinien interagieren mit beiden Ebenen als kombiniertes Framework. Apigee verwaltet die Beziehung zwischen den Ebenen.
Ebene 1 ist ein In-Memory-Cache (L1) für einen schnellen Zugriff. Jeder Message Processor-Knoten verfügt über einen eigenen In-Memory-Cache für die schnellste Antwort auf Anfragen.
L1 ist ein kurzlebiger (1 Sekunde) In-Memory-Cache.
Wenn das Speicherlimit erreicht ist, entfernt Apigee die Cache-Einträge aus dem Speicher (sie sind jedoch weiterhin im nichtflüchtigen L2-Cache enthalten), damit der Arbeitsspeicher für andere Prozesse verfügbar bleibt.
L1 wird mit einem kurzlebigen 1-Sekunden-Cache bereitgestellt, um eine schnellere Suche für gleichzeitige Anfragen mit demselben Cache-Schlüssel zu ermöglichen.
Ebene 2 ist ein nichtflüchtiger Cache (L2) unter dem In-Memory-Cache. Alle Message Processor-Knoten nutzen gemeinsam einen Cache-Datenspeicher (Cassandra) für nichtfllüchtige Cache-Einträge.
Cache-Einträge bleiben auch dann erhalten, wenn sie aus dem L1-Cache entfernt werden, beispielsweise wenn die In-Memory-Limits erreicht wurden.
Da der nichtflüchtige Cache von den Message Processors gemeinsam (auch in verschiedenen Regionen) genutzt werden, sind Cache-Einträge verfügbar, unabhängig davon, welcher Knoten eine Anfrage für die im Cache gespeicherten Daten empfängt.
Nur Einträge einer bestimmten Größe können im Cache gespeichert werden, und andere Limits für den Cache sind möglich.
Weitere Informationen finden Sie unter Cache-Limits verwalten.
Der Cache-Inhalt in L2 wird mit dem AES-256-Algorithmus verschlüsselt.
Die Daten werden vor dem Verwenden durch die Laufzeit entschlüsselt und vor dem Schreiben in L2 verschlüsselt. Der Verschlüsselungsprozess ist für Nutzer nicht sichtbar.
So verwenden Richtlinien den Cache
Im Folgenden wird beschrieben, wie Apigee Cache-Einträge verarbeitet, während die Caching-Richtlinien ausgeführt werden.
Wenn eine Richtlinie einen neuen Eintrag in den Cache schreibt (PopulateCache- oder ResponseCache-Richtlinie):
Apigee schreibt den Eintrag in den In-Memory-L1-Cache nur für den Message Processor, der die Anfrage verarbeitet hat. Wenn die Speicherlimits für den Message Processor erreicht sind, bevor der Eintrag abläuft, entfernt Apigee den Eintrag aus dem L1-Cache.
Apigee schreibt den Eintrag auch in den L2-Cache.
Wenn eine Richtlinie aus dem Cache liest (LookupCache- oder ResponseCache-Richtlinie):
Apigee sucht zuerst nach dem In-Memory-L1-Cache des Message Processors, der die Anfrage verarbeitet.
Wenn kein entsprechender In-Memory-Eintrag vorhanden ist, sucht Apigee nach dem Eintrag im nichtflüchtigen L2-Cache.
Wenn sich der Eintrag nicht im nichtflüchtigen Cache befindet:
ResponseCache-Richtlinie: Apigee gibt die tatsächliche Antwort vom Ziel an den Client zurück und speichert den Eintrag im Cache, bis er abläuft oder ungültig wird.
Der Message Processor, der die Anfrage empfängt, löscht den Eintrag aus dem In-Memory-L1-Cache (1-Sekunden-Cache) und löscht den Eintrag ebenfalls aus dem L2-Cache.
Nach einer Aktualisierung oder Entwertung ist es möglich, dass die anderen Message Processors noch weiter an dem L1-Cache festhalten.
Da L1 so konfiguriert ist, dass er in einer Sekunde abläuft, ist kein Löschen/Aktualisieren-Ereignis erforderlich, um den Eintrag aus L1 zu entfernen.
Cache-Limits verwalten
Mithilfe der Konfiguration können Sie einige Aspekte des Cache verwalten. Der für den speicherinterne Cache verfügbare Speicherplatz ist durch Systemressourcen begrenzt und kann nicht konfiguriert werden.
Für den Cache gelten die folgenden Einschränkungen:
Cache-Limits: Es gelten verschiedene Cache-Limits, z. B. Name und Wertgröße, Gesamtzahl der Caches, Anzahl der Elemente in einem Cache und Ablauf.
Cache im Arbeitsspeicher (L1). Die Speicherlimits für Ihren Cache können nicht konfiguriert werden. Die Limits werden von Apigee für jeden Nachrichtenprozessor festgelegt, der Caches für mehrere Kunden hostet.
In einer gehosteten Cloud-Umgebung, in der In-Memory-Caches für alle Kundenbereitstellungen über mehrere gemeinsam genutzte Message Processors gehostet werden, besitzt jeder Message Processor einen über Apigee-konfigurierbaren Schwellenwert für den Arbeitsspeicher, damit das Caching nicht den gesamten Arbeitsspeicher der Anwendung verbraucht. Wenn der Schwellenwert für einen bestimmten Message Processor überschritten wird, werden Cache-Einträge, deren letzte Verwendung am längsten zurückliegt, aus dem Arbeitsspeicher gelöscht. Aus dem Arbeitsspeicher entfernte Einträge bleiben im L2-Cache solange gespeichert, bis sie abgelaufen oder ungültig sind.
Nichtflüchtiger Cache (L2): Aus dem In-Memory-Cache entfernte Einträge verbleiben gemäß den konfigurierbaren Einstellungen für die Gültigkeitsdauer im nichtflüchtigen Cache erhalten.
Konfigurierbare Optimierungen
In der folgenden Tabelle sind Einstellungen aufgeführt, mit denen Sie die Cache-Leistung optimieren können.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
