Saat kebijakan penyimpanan dalam cache dijalankan, cache L1 jangka pendek
akan dibuat. Setelah satu detik, jika item yang di-cache tidak diakses, item tersebut akan dipertahankan dalam database
tempat item tersebut tersedia untuk semua pemroses pesan yang di-deploy di lingkungan hingga cache berakhir.
Anda mengonfigurasi waktu habis masa berlaku langsung dalam kebijakan cache.
Tingkat cache dalam memori dan persisten
Cache bersama dan lingkungan dibangun di sistem dua tingkat yang terdiri dari tingkat dalam memori
dan tingkat persisten seperti yang ditunjukkan pada gambar berikut. Kebijakan berinteraksi dengan kedua tingkat
sebagai framework gabungan. Apigee mengelola hubungan antara tingkat.
Level 1 adalah cache dalam memori (L1) untuk akses cepat. Setiap node pemrosesan pesan (MP)
memiliki cache dalam memori sendiri untuk memberikan respons tercepat terhadap permintaan.
L1 adalah cache dalam memori yang berumur pendek (1 detik).
Saat batas memori tercapai, Apigee akan menghapus entri cache dari memori (meskipun
entri tersebut masih disimpan dalam cache persisten L2) untuk memastikan memori tetap tersedia
untuk proses lain.
L1 disediakan dengan cache satu detik yang berumur pendek untuk melakukan pencarian yang lebih cepat untuk permintaan serentak dengan kunci cache yang sama.
Level 2 adalah cache persisten (L2) di bawah cache dalam memori. Semua node pemrosesan pesan
berbagi penyimpanan data cache (Cassandra) untuk mempertahankan entri cache.
Entri cache tetap ada di sini meskipun setelah dihapus dari cache L1, seperti saat
batas dalam memori tercapai.
Karena cache persisten dibagikan di seluruh pemroses pesan (bahkan di berbagai
region), entri cache tersedia terlepas dari node mana yang menerima permintaan untuk
data yang di-cache.
Hanya entri dengan ukuran tertentu yang dapat di-cache, dan batas cache lainnya berlaku.
Lihat Mengelola batas cache.
Konten cache di L2 dienkripsi dengan algoritma AES-256.
Data didekripsi sebelum digunakan oleh runtime dan dienkripsi sebelum ditulis ke L2. Jadi, proses enkripsi tidak terlihat oleh pengguna.
Cara kebijakan menggunakan cache
Berikut ini menjelaskan cara Apigee menangani entri cache saat kebijakan caching Anda
berfungsi.
Saat kebijakan menulis entri baru ke cache (kebijakan PopulateCache atau
ResponseCache):
Apigee menulis entri ke cache L1 dalam memori hanya di pemroses pesan
yang menangani permintaan. Jika batas memori pada pemroses pesan tercapai
sebelum entri berakhir, Apigee akan menghapus entri dari cache L1.
Apigee juga menulis entri ke cache L2.
Saat kebijakan membaca dari cache (kebijakan LookupCache atau ResponseCache):
Apigee pertama-tama mencari entri di cache L1 dalam memori dari pemroses pesan yang
menangani permintaan.
Jika tidak ada entri dalam memori yang sesuai, Apigee akan mencari entri di cache persisten L2.
Kebijakan ResponseCache: Apigee menampilkan respons sebenarnya dari target ke
klien dan menyimpan entri dalam cache hingga masa berlakunya berakhir atau dibatalkan.
Prosesor pesan yang menerima permintaan akan menghapus entri dari cache L1 dalam memori satu detik
dan juga menghapus entri dari cache L2.
Setelah pembaruan atau pembatalan, kemungkinan pemroses pesan lainnya masih menyimpan cache L1 dalam memori.
Karena L1 dikonfigurasi agar berakhir dalam satu detik, tidak ada peristiwa penghapusan/pembaruan
yang diperlukan untuk menghapus entri dari L1.
Mengelola batas cache
Melalui konfigurasi, Anda dapat mengelola beberapa aspek cache. Ruang keseluruhan
yang tersedia untuk cache dalam memori dibatasi oleh resource sistem dan tidak dapat dikonfigurasi.
Batasan berikut berlaku untuk cache:
Batas cache: Berbagai batas cache
berlaku, seperti ukuran nama dan nilai, total jumlah cache, jumlah item dalam cache,
dan masa berlaku.
Cache dalam memori (L1). Batas memori untuk cache Anda tidak dapat dikonfigurasi. Batas ditetapkan oleh Apigee untuk setiap pemroses pesan yang menghosting cache untuk beberapa pelanggan.
Di lingkungan cloud yang dihosting, tempat cache dalam memori untuk semua deployment pelanggan dihosting di beberapa pemroses pesan bersama, setiap pemroses memiliki batas persentase memori yang dapat dikonfigurasi Apigee untuk memastikan bahwa caching tidak menggunakan semua memori aplikasi. Saat nilai minimum terlampaui untuk pemroses pesan tertentu, entri cache akan dikeluarkan
dari memori berdasarkan penggunaan yang paling jarang. Entri yang dikeluarkan dari memori tetap berada di cache L2
hingga masa berlakunya berakhir atau dibatalkan.
Cache persisten (L2). Entri yang dikeluarkan dari cache dalam memori
tetap berada di cache persisten sesuai dengan setelan time-to-live yang dapat dikonfigurasi.
Pengoptimalan yang dapat dikonfigurasi
Tabel berikut mencantumkan setelan yang dapat Anda gunakan untuk mengoptimalkan performa cache.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
