Membandingkan kebijakan Quota dan SpikeArrest

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Baca dokumentasi Apigee Edge.

Poin Penting: Kebijakan Quota dan SpikeArrest menghitung permintaan dan mengambil tindakan jika nilai minimum permintaan yang ditentukan terlampaui. Namun, perlu diketahui bahwa mekanisme yang digunakan kebijakan ini untuk menghitung permintaan tidak sama.

Meskipun SpikeArrest mempertahankan jumlah dengan keandalan tinggi, SpikeArrest dirancang untuk menggunakan cache upaya terbaik Redis untuk menyimpan jumlahnya. Karena cache tidak direplikasi, ada kasus saat jumlah dapat hilang, seperti memulai ulang server cache, atau kasus langka lainnya.

Karena alasan ini, sebaiknya jangan gunakan SpikeArrest untuk kasus penggunaan yang memerlukan penghitungan yang akurat. Hanya kebijakan kuota sinkron yang menawarkan penghitungan yang akurat di semua region dalam jangka waktu tertentu.

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 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.
Dapatkan detail selengkapnya:	Kebijakan kuota	Kebijakan SpikeArrest

Tips: Anda juga dapat menggunakan hal berikut untuk melindungi backend yang lambat/lelet tanpa memengaruhi performa API:

• Membuat alur bersama yang dapat digunakan kembali: Menggabungkan kebijakan dan resource ke dalam alur bersama yang dapat Anda gunakan dari beberapa proxy API, dan bahkan dari alur bersama lainnya.
• Menghubungkan proxy API secara berantai: Menentukan bahwa satu proxy adalah endpoint target dari proxy lain, yang menghubungkan kedua proxy secara efektif dalam rantai proxy. Menghubungkan proxy dengan cara ini dapat membantu Anda menghindari hop jaringan, sehingga meningkatkan performa secara keseluruhan.