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 mempertahankan jumlah dengan keandalan tinggi, SpikeArrest didesain untuk menggunakan cache upaya terbaik Redis untuk menyimpan jumlahnya. Karena cache tidak direplikasi, ada kasus saat jumlah mungkin hilang, seperti memulai ulang server cache, atau kasus langka lainnya.

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

Gunakan diagram perbandingan di bawah untuk membantu Anda memutuskan kebijakan mana yang harus digunakan untuk kasus penggunaan pembatasan kapasitas:

	Kuota	SpikeArrest
Gunakan untuk:	Batasi jumlah panggilan proxy API yang dapat dilakukan oleh 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 diperlukan penghitungan yang akurat.	Batasi jumlah panggilan API yang dapat dilakukan terhadap proxy API pada semua konsumen selama periode waktu tertentu (biasanya singkat). Kebijakan Kuota lebih cocok untuk menetapkan batas pada interval waktu yang lebih lama seperti hari, minggu, bulan, atau tahun.
Jangan gunakan untuk:	Jangan gunakan untuk melindungi backend target proxy API dari lonjakan traffic. Untuk itu, gunakan kebijakan SpikeArrest.	Jangan menggunakannya untuk menghitung dan membatasi jumlah koneksi yang dapat dibuat aplikasi ke backend target proxy API Anda selama jangka waktu tertentu. Catatan: Untuk kasus penggunaan yang memerlukan penghitungan akurat, gunakan kebijakan Kuota.
Menyimpan jumlah?	Ya	Tidak
Praktik terbaik untuk melampirkan kebijakan:	Lampirkan ke ProxyEndpoint Request PreFlow, biasanya setelah autentikasi pengguna. Hal ini memungkinkan kebijakan untuk memeriksa penghitung kuota di titik entri proxy API Anda.	Lampirkan ke ProxyEndpoint Request PreFlow, umumnya di awal alur. Fungsi ini memberikan perlindungan lonjakan pada titik entri proxy API Anda.
Kode status HTTP saat batas telah tercapai:	429 (Layanan Tidak Tersedia)	429 (Layanan Tidak Tersedia)
Sebaiknya Anda tahu:	Penghitung kuota disimpan di Cassandra. Konfigurasi kebijakan untuk menyinkronkan penghitung secara asinkron guna menyimpan resource. Sinkronisasi penghitung asinkron dapat menyebabkan penundaan dalam respons pembatasan kapasitas, yang mungkin mengizinkan panggilan sedikit melebihi batas yang telah Anda tetapkan.	Memungkinkan Anda memilih antara algoritma "menghaluskan" atau algoritma penghitungan yang efektif. Permintaan pertama melancarkan 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 berturut-turut. Selain itu, kelancaran tidak dikoordinasikan di seluruh Pemroses Pesan.
Dapatkan detail selengkapnya:	Kebijakan kuota	Kebijakan SpikeArrest

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

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