Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Coba lagi perilaku

Perilaku coba lagi mencakup pengaturan mengenai bagaimana SDKs upaya untuk memulihkan dari kegagalan yang dihasilkan dari permintaan yang dibuat Layanan AWS.

Memilih antara standard dan adaptive coba lagi mode

Kami menyarankan Anda menggunakan mode standard coba lagi kecuali Anda yakin bahwa penggunaan Anda lebih cocok untukadaptive.

Jika Anda memilih untuk menggunakan adaptive mode, aplikasi Anda harus membangun klien yang dirancang di sekitar setiap sumber daya yang mungkin dibatasi. Sumber daya, dalam hal ini, disetel lebih baik daripada hanya memikirkan masing-masing Layanan AWS. Layanan AWS dapat memiliki dimensi tambahan yang mereka gunakan untuk membatasi permintaan. Mari kita gunakan layanan Amazon DynamoDB sebagai contoh. DynamoDB menggunakan Wilayah AWS ditambah tabel yang diakses ke permintaan throttle. Ini berarti bahwa satu tabel yang diakses kode Anda mungkin dibatasi lebih dari yang lain. Jika kode Anda menggunakan klien yang sama untuk mengakses semua tabel, dan permintaan ke salah satu tabel tersebut dibatasi, maka mode coba lagi adaptif akan mengurangi tingkat permintaan untuk semua tabel. Kode Anda harus dirancang untuk memiliki satu klien per egion-and-table pasangan R. Jika Anda mengalami latensi tak terduga saat menggunakan adaptive mode, lihat spesifiknya AWS panduan dokumentasi untuk layanan yang Anda gunakan.

Coba lagi detail implementasi mode

Bagian AWS SDKsgunakan ember token untuk memutuskan apakah permintaan harus dicoba lagi dan (dalam kasus mode adaptive coba lagi) seberapa cepat permintaan harus dikirim. Dua bucket token digunakan olehSDK: ember token coba lagi dan bucket token rate permintaan.

Berikut ini adalah pseudocode tingkat tinggi untuk mode standard dan adaptive coba lagi:

MakeSDKRequest() {
  attempts = 0
  loop {
    GetSendToken()
    response = SendHTTPRequest()
    RequestBookkeeping(response)
    if not Retryable(response)
      return response
    attempts += 1
    if attempts >= MAX_ATTEMPTS:
      return response
    if not HasRetryQuota(response)
      return response
    delay = ExponentialBackoff(attempts)
    sleep(delay)
  }
}

Berikut ini adalah rincian lebih lanjut tentang komponen yang digunakan dalam pseudocode:

GetSendToken:

Langkah ini hanya digunakan dalam mode adaptive coba lagi. Langkah ini memperoleh token dari bucket token rate permintaan. Jika token tidak tersedia, itu akan menunggu hingga tersedia. Anda SDK mungkin memiliki opsi konfigurasi yang tersedia untuk gagal permintaan alih-alih menunggu. Token dalam bucket diisi ulang pada tingkat yang ditentukan secara dinamis, berdasarkan jumlah respons pelambatan yang diterima oleh klien.

SendHTTPRequest:

Langkah ini mengirimkan permintaan ke AWS. Kebanyakan AWS SDKsgunakan HTTP pustaka yang menggunakan kumpulan koneksi untuk menggunakan kembali koneksi yang ada saat membuat HTTP permintaan. Umumnya, koneksi digunakan kembali jika permintaan gagal karena kesalahan pelambatan tetapi tidak jika permintaan gagal karena kesalahan sementara.

RequestBookkeeping:

Token ditambahkan ke ember token jika permintaan berhasil. Hanya untuk mode adaptive coba lagi, tingkat pengisian bucket token rate permintaan diperbarui berdasarkan jenis respons yang diterima.

Retryable:

Langkah ini menentukan apakah respons dapat dicoba ulang berdasarkan hal berikut:

Kesalahan sementara (kode HTTP status 400, 408, 500, 502, 503, dan 504) dan kesalahan pelambatan (kode HTTP status 400, 403, 429, 502, 503, dan 509) semuanya berpotensi dicoba ulang. SDKperilaku coba lagi ditentukan dalam kombinasi dengan kode kesalahan atau data lain dari layanan.

MAX_ATTEMPTS:

Jumlah default upaya maksimum diatur oleh retry_mode pengaturan, kecuali diganti oleh pengaturan. max_attempts

HasRetryQuota

Langkah ini memperoleh token dari ember token coba lagi. Jika ember token coba lagi kosong, permintaan tidak akan dicoba lagi.

ExponentialBackoff

Untuk kesalahan yang dapat dicoba lagi, penundaan coba lagi dihitung menggunakan backoff eksponensial terpotong. SDKsPenggunaan backoff eksponensial biner terpotong dengan jitter. Algoritma berikut menunjukkan bagaimana jumlah waktu tidur, dalam detik, didefinisikan untuk respons permintaani:

seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)

Dalam algoritma sebelumnya, nilai-nilai berikut berlaku:

b = random number within the range of: 0 <= b <= 1

r = 2

MAX_BACKOFF = 20 secondsuntuk sebagian besarSDKs. Lihat SDK panduan atau kode sumber khusus Anda untuk konfirmasi.

Kompatibilitas dengan AWS SDKs

Berikut ini SDKs mendukung fitur dan pengaturan yang dijelaskan dalam topik ini. Setiap pengecualian sebagian dicatat. Pengaturan properti JVM sistem apa pun didukung oleh AWS SDK for Java dan AWS SDK for Kotlin hanya.