Membandingkan kebijakan Quota dan SpikeArrest

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

Poin Penting: Kuota dan Kebijakan SpikeArrest menghitung permintaan dan mengambil tindakan jika permintaan tertentu nilai minimum terlampaui. Namun, perhatikan bahwa mekanisme yang digunakan untuk menghitung permintaan tersebut tidak sama.

Meskipun SpikeArrest mempertahankan jumlah dengan keandalan yang tinggi, ia dirancang untuk menggunakan Redis upaya terbaik untuk menyimpan jumlahnya. Karena cache tidak direplikasi, ada kasus di mana jumlahnya hilang, seperti memulai ulang server {i>cache<i}, atau kasus yang jarang terjadi.

Karena alasan ini, sebaiknya terhadap penggunaan SpikeArrest untuk kasus penggunaan yang membutuhkan penghitungan akurat. Hanya elemen sinkron Kebijakan kuota 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 melalui periode waktu tertentu. Kebijakan SpikeArrest lebih cocok untuk pembatasan kapasitas dalam waktu yang lebih singkat interval seperti detik atau menit. Pertimbangkan Kuota jika diperlukan penghitungan yang akurat.	Membatasi 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 waktu yang lebih lama interval seperti hari, minggu, bulan, atau tahun.
Jangan gunakan untuk:	Jangan menggunakannya untuk melindungi backend target proxy API Anda dari lonjakan traffic. Untuk itu, gunakan kebijakan SpikeArrest.	Jangan menggunakannya untuk menghitung dan membatasi jumlah koneksi yang dapat dibuat aplikasi ke API Anda backend target proxy selama jangka waktu tertentu. Catatan: Untuk kasus penggunaan apa pun yang memerlukan penghitungan yang akurat, gunakan kebijakan Kuota.
Menyimpan hitungan?	Ya	Tidak
Praktik terbaik untuk melampirkan kebijakan:	Lampirkan ke PreFlow Permintaan ProxyEndpoint, umumnya setelah otentikasi pengguna. Tindakan ini memungkinkan kebijakan memeriksa penghitung kuota di titik entri API Anda {i>proxy<i}.	Lampirkan ke ProxyEndpoint Request PreFlow, umumnya dengan awal alur. Hal 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. Mengonfigurasi kebijakan untuk menyinkronkan penghitung secara asinkron guna menyimpan Google Cloud Platform. Sinkronisasi penghitung asinkron dapat menyebabkan penundaan pada pembatasan kapasitas yang memungkinkan panggilan sedikit melebihi batas yang telah ditetapkan.	Memungkinkan Anda memilih antara "halus" atau algoritma penghitungan efektif. Tujuan yang pertama memperlancar jumlah permintaan yang dapat terjadi dalam jangka waktu tertentu, dan membatasi jumlah total permintaan yang dapat terjadi dalam jangka waktu tertentu, seberapa cepat mereka dikirim secara berurutan. Selain itu, penghalusan tidak terkoordinasi dalam Pemroses Pesan.
Dapatkan detail selengkapnya:	Kebijakan kuota	SpikeArrest kebijakan

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 API {i>proxy<i}, dan bahkan dari alur bersama lainnya.
• Membuat rantai proxy API secara bersamaan: Tentukan bahwa satu proxy merupakan endpoint target dari proxy lainnya, secara efektif menghubungkan dua {i>proxy<i} dalam rantai {i>proxy<i}. Membuat rantai {i>proxy<i} dengan cara ini dapat membantu Anda menghindari {i>network hop<i}, dan meningkatkan kinerja keseluruhan.