Gunakan diagram perbandingan di bawah untuk membantu Anda memutuskan kebijakan mana yang akan digunakan untuk
kasus penggunaan pembatasan kapasitas:
Kuota
SpikeArrest
Gunakan untuk:
Batasi jumlah panggilan proxy API yang dapat dilakukan aplikasi developer atau developer selama
jangka waktu tertentu. Kebijakan SpikeArrest lebih cocok untuk pembatasan kapasitas dalam interval waktu yang lebih singkat seperti detik atau menit. Pertimbangkan Kuota jika penghitungan yang akurat merupakan persyaratan.
Membatasi jumlah panggilan API yang dapat dilakukan terhadap proxy API di semua konsumen
selama jangka waktu tertentu (biasanya singkat). Kebijakan Kuota lebih cocok untuk menetapkan batas pada interval waktu yang lebih lama seperti hari, minggu, bulan, atau tahun.
Jangan menggunakannya untuk:
Jangan menggunakannya untuk melindungi backend target proxy API Anda dari lonjakan traffic.
Untuk melakukannya, gunakan kebijakan SpikeArrest.
Jangan menggunakannya untuk menghitung dan membatasi jumlah koneksi yang dapat dilakukan aplikasi ke backend target proxy API Anda selama jangka waktu tertentu. Catatan: Untuk kasus penggunaan apa pun yang memerlukan penghitungan yang akurat, gunakan kebijakan Kuota.
Menyimpan jumlah?
Ya
Tidak
Praktik terbaik untuk melampirkan kebijakan:
Lampirkan ke ProxyEndpoint Request PreFlow, umumnya setelah
autentikasi pengguna.
Hal ini memungkinkan kebijakan memeriksa penghitung kuota di titik entri proxy API Anda.
Lampirkan ke ProxyEndpoint Request PreFlow, umumnya di awal
alur.
Hal ini memberikan perlindungan lonjakan di titik entri proxy API Anda.
Kode status HTTP saat batas tercapai:
429 (Layanan Tidak Tersedia)
429 (Layanan Tidak Tersedia)
Penting untuk diketahui:
Penghitung kuota disimpan di Cassandra.
Konfigurasikan kebijakan untuk menyinkronkan penghitung secara asinkron untuk menghemat
resource.
Sinkronisasi penghitung asinkron dapat menyebabkan penundaan dalam respons pembatasan kapasitas, yang dapat memungkinkan panggilan sedikit melebihi batas yang telah Anda tetapkan.
Memungkinkan Anda memilih antara algoritma "pelurusan" atau algoritma jumlah efektif. Yang pertama
meratakan jumlah permintaan yang dapat terjadi dalam jangka waktu tertentu, dan yang kedua
membatasi jumlah total permintaan yang dapat terjadi dalam jangka waktu tertentu, terlepas dari
seberapa cepat permintaan tersebut dikirim secara berurutan. Selain itu, penghalusan tidak dikoordinasikan di seluruh
Message Processor.
[[["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-08-19 UTC."],[[["\u003cp\u003eThis content focuses on the Quota and SpikeArrest policies within Apigee and Apigee hybrid, which are used to manage request thresholds.\u003c/p\u003e\n"],["\u003cp\u003eThe Quota policy is recommended for use cases requiring precise request counting over longer durations like days, weeks, months, or years, offering accurate counting across all regions.\u003c/p\u003e\n"],["\u003cp\u003eSpikeArrest is better suited for rate limiting over short intervals, such as seconds or minutes, and for protecting backend services from sudden traffic spikes, but its request counting may not be entirely accurate due to its use of a Redis cache.\u003c/p\u003e\n"],["\u003cp\u003eBoth the Quota and SpikeArrest policies trigger a \u003ccode\u003e429\u003c/code\u003e (Service Unavailable) HTTP status code when request limits are reached, indicating a temporary denial of service.\u003c/p\u003e\n"],["\u003cp\u003eShared flows and chaining proxies can be utilized to protect slower backends without impacting API performance.\u003c/p\u003e\n"]]],[],null,["# Comparing Quota and SpikeArrest policies\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\n| **Key Point:** The [Quota](/apigee/docs/api-platform/reference/policies/quota-policy) and [SpikeArrest](/apigee/docs/api-platform/reference/policies/spike-arrest-policy) policies both count requests and take action if a specified request threshold is exceeded. Be aware, however, that the mechanisms by which these policies count requests are not the same.\n|\n|\n| While SpikeArrest maintains counts with high reliability, it is designed to use a\n| [Redis\n| best-effort cache](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/redis) to store its counts. Because the cache is not replicated, there are cases where counts may be\n| lost, such as a restart of the cache servers, or other rare cases.\n|\n| For these reasons, we recommend\n| against using SpikeArrest for use cases that require accurate counting. Only the synchronous\n| Quota policy offers accurate counting across all regions in a given timeframe.\n\nUse the comparison chart below to help you decide which policy to use to\nfor your rate limiting use case:\n\n| **Tip:** You can also use the following to protect slow/sluggish backends without impacting the performance of the APIs:\n|\n| - [Creating reusable shared flows:](/apigee/docs/api-platform/fundamentals/shared-flows) Combine policies and resources into a shared flow that you can consume from multiple API proxies, and even from other shared flows.\n| - [Chaining API proxies together](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies): Specify that one proxy is the target endpoint of another, effectively connecting the two proxies in a proxy chain. Chaining proxies in this way can help you avoid a network hop, and so improve overall performance."]]
