Strategi percobaan ulang

Halaman ini menjelaskan praktik terbaik untuk mencoba kembali permintaan yang gagal ke Model Armor API.

Untuk permintaan yang aman untuk dicoba lagi, sebaiknya gunakan backoff eksponensial terpotong dengan jitter yang disisipkan.

Ringkasan backoff eksponensial terpotong

Setiap permintaan ke Model Armor API dapat berhasil atau gagal. Jika aplikasi Anda mencoba kembali permintaan yang gagal tanpa menunggu, aplikasi tersebut mungkin mengirimkan sejumlah besar percobaan ulang ke Model Armor dalam waktu singkat. Akibatnya, Anda mungkin melebihi kuota dan batas yang berlaku untuk setiap resource Model Armor di Google Cloud project Anda.

Untuk menghindari pemicuan masalah ini, kami sangat merkomendasikan agar Anda menggunakan backoff eksponensial terpotong dengan jitter yang disisipkan, yang merupakan strategi penanganan error standar untuk aplikasi jaringan. Dalam pendekatan ini, klien secara berkala mencoba kembali permintaan yang gagal dengan penundaan yang meningkat secara eksponensial di antara percobaan ulang. Penundaan acak kecil, yang dikenal sebagai jitter, juga disisipkan di antara percobaan ulang. Penundaan acak ini membantu mencegah terjadinya rentetan percobaan ulang yang tersinkronisasi dari beberapa klien yang juga dikenal sebagai masalah kawanan guntur.

Algotitma backoff eksponensial

Algoritme berikut menerapkan backoff eksponensial terpotong dengan jitter:

  1. Kirim permintaan ke Model Armor.
  2. Jika permintaan gagal, tunggu 1 + random-fraction detik, lalu coba lagi permintaan tersebut.
  3. Jika permintaan gagal, tunggu 2 + random-fraction detik, lalu coba lagi permintaan tersebut.
  4. Jika permintaan gagal, tunggu 4 + random-fraction detik, lalu coba lagi permintaan tersebut.
  5. Lanjutkan pola ini, menunggu 2n + random-fraction detik setelah setiap percobaan ulang, hingga maximum-backoff kali.
  6. Setelah deadline detik, berhenti mencoba lagi permintaan tersebut.

Gunakan nilai berikut saat Anda mengimplementasikan algoritme:

  • Sebelum setiap percobaan ulang, waktu tunggu adalah min((2n + random-fraction), maximum-backoff), dengan n dimulai dari 0 dan bertambah 1 untuk setiap percobaan ulang.
  • Ganti random-fraction dengan nilai pecahan acak yang kurang dari atau sama dengan 1. Gunakan nilai yang berbeda untuk setiap percobaan ulang. Menambahkan nilai acak ini mencegah klien menjadi tersinkronisasi dan mengirim percobaan ulang dalam jumlah besar secara bersamaan.
  • Ganti maximum-backoff dengan jumlah waktu maksimum, dalam detik, untuk menunggu di antara percobaan ulang. Nilai yang umum adalah 32 atau 64 (25 atau 26) detik. Pilih nilai yang paling sesuai untuk kasus penggunaan Anda.
  • Ganti deadline dengan jumlah detik maksimum untuk terus mengirim percobaan ulang. Pilih nilai yang mencerminkan kasus penggunaan Anda. Misalnya, dalam pipeline continuous integration/deployment berkelanjutan (CI/CD) yang tidak terlalu sensitif terhadap waktu, Anda dapat menetapkan deadline ke 300 detik (5 menit).

Jenis error yang dapat dicoba ulang

Gunakan strategi percobaan ulang ini untuk semua permintaan ke Model Armor API yang menampilkan kode error 500, 502, 503, atau 504.

Secara opsional, Anda dapat menggunakan strategi percobaan ulang ini untuk permintaan ke Model Armor API yang menampilkan kode error 429.