Mencoba lagi permintaan yang gagal

Halaman ini menjelaskan praktik terbaik untuk mencoba kembali permintaan yang gagal ke Identity and Access Management (IAM) API.

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

Ringkasan backoff eksponensial terpotong

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

Untuk menghindari pemicuan masalah ini, kami sangat merkomendasikan agar Anda menggunakan backoff eksponensial terpotong dengan jitter, yang disisipkan, yang merupakan strategi epenanganan 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 IAM.
  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 IAM API yang menampilkan kode error 500, 502, 503, atau 504.

Secara opsional, Anda dapat menggunakan strategi percobaan ulang ini untuk permintaan ke IAM API yang menampilkan kode error 404. Pembacaan IAM adalah pembacaan dengan konsistensi tertunda; Akibatnya, resource mungkin tidak langsung terlihat setelah Anda membuatnya, yang dapat menyebabkan error 404.

Selain itu, gunakan versi modifikasi dari strategi percobaan ulang ini untuk semua permintaan ke IAM API yang menampilkan kode error 409 dan status ABORTED. Jenis error ini menunjukkan masalah konkurensi; misalnya, Anda mungkin mencoba mengupdate kebijakan perizinan yang telah ditimpa oleh klien lain. Untuk jenis error ini, Anda harus selalu mencoba ulang seluruh rangkaian permintaan baca-ubah-tulis., menggunakan backoff eksponensial terpotong dengan jitter yang disisipkanj. Jika Anda hanya mencoba ulang operasi tulis, permintaan tersebut akan terus gagal.

Langkah selanjutnya