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

Perilaku coba lagi

Ketika permintaan Layanan AWS gagal karena kesalahan sementara atau pelambatan, SDK dapat secara otomatis mencoba kembali permintaan tersebut. Halaman ini mencakup cara mengonfigurasi percobaan ulang dan cara kerjanya secara internal.

Mengkonfigurasi percobaan ulang

Anda mengontrol strategi coba ulang yang digunakan SDK dan berapa kali SDK mencoba lagi.

Memilih mode coba lagi

Mode coba lagi menentukan bagaimana SDK berperilaku ketika permintaan gagal. Tersedia tiga mode: standar, adaptif, dan warisan.

Mode standar (default)

Mode standar mencoba lagi permintaan gagal menggunakan backoff eksponensial dengan jitter. Ini menggunakan penundaan yang lebih pendek untuk kesalahan sementara (seperti batas waktu jaringan) dan penundaan yang lebih lama untuk kesalahan pelambatan (sepertiThrottlingException).

Mode standar mencakup kuota percobaan ulang, bucket token yang mengurangi token untuk setiap percobaan ulang dan mengisi kembali token saat permintaan berhasil. Ketika token yang tersedia habis, SDK mengembalikan kesalahan tanpa mencoba lagi, sehingga aplikasi Anda gagal dengan cepat alih-alih menunggu percobaan ulang yang tidak mungkin berhasil. Ini juga membantu gangguan layanan diselesaikan lebih cepat dengan mengurangi lalu lintas coba ulang. Selama operasi normal, kuota tetap penuh dan tidak berpengaruh. Kuota percobaan ulang tidak pernah menunda atau memblokir permintaan awal. Hanya percobaan ulang yang terpengaruh. Lihat perinciannya di Kuota coba lagi (bucket token).

Gunakan mode standar kecuali Anda memiliki alasan khusus untuk memilih mode lain.

Mode adaptif

Mode adaptif mencakup semuanya dalam mode standar, ditambah pembatas laju sisi klien. Pembatas kecepatan melacak respons pelambatan dan menyesuaikan kecepatan pengiriman permintaan SDK. Tidak seperti mode standar, mode adaptif dapat menunda atau memblokir permintaan awal, bukan hanya percobaan ulang, ketika pelambatan terdeteksi.

Pembatas tarif beroperasi per instance klien SDK. Semua permintaan dari klien memiliki batas tarif yang sama, terlepas dari operasi API atau sumber daya yang ditargetkan.

Kapan menggunakan mode adaptif:

Kapan tidak menggunakan mode adaptif:

Mode adaptif tidak disarankan sebagai default umum.

Modus warisan

Mode lama adalah perilaku coba ulang setiap SDK yang digunakan sebelum mode standar diperkenalkan. Itu tidak termasuk kuota percobaan ulang standar. Beberapa SDK (seperti Java) memiliki implementasi kuota percobaan ulang sendiri dalam mode lama, tetapi perilakunya tidak konsisten di seluruh SDK. Tanpa kuota standar, klien terus mencoba lagi pada tingkat penuh selama gangguan layanan. Ini mengikat utas dan koneksi pada permintaan yang tidak mungkin berhasil, sambil menambahkan beban yang dapat menunda pemulihan layanan.

Mode Legacy bervariasi di seluruh SDK. Jumlah percobaan ulang, waktu mundur, set kesalahan yang dapat dicoba ulang, dan perilaku pembatasan berbeda antar bahasa. Kode yang bergantung pada perilaku coba ulang lama mungkin berperilaku berbeda saat dipindahkan antar SDK.

Tersedia dalam: Java, Python, Ruby, PHP, C ++, CLI

Tidak tersedia di: .NET, Go, Kotlin, Rust, Swift, JavaScript

Mode Legacy ada untuk kompatibilitas mundur. Jika saat ini Anda menggunakan mode lama, beralihlah ke mode standar.

Setelan coba lagi

Pengaturan berikut mengontrol perilaku coba lagi. Anda dapat mengaturnya melalui variabel lingkungan, file konfigurasi bersama (~/.aws/config), atau konfigurasi klien dalam kode.

Nilai percobaan maksimum 3 berarti SDK membuat satu permintaan awal dan hingga dua percobaan ulang. Tetapkan upaya maksimal 1 untuk menonaktifkan percobaan ulang sepenuhnya.

Prioritas konfigurasi

Saat Anda menentukan setelan yang sama di beberapa tempat, SDK menyelesaikan nilai menggunakan prioritas berikut, dari tertinggi ke terendah:

Ini mengikuti prioritas konfigurasi AWS SDK standar. Nilai yang ditetapkan pada tingkat yang lebih tinggi selalu mengesampingkan nilai yang ditetapkan pada tingkat yang lebih rendah. Misalnya, jika Anda menyet AWS_RETRY_MODE=adaptive el sebagai variabel lingkungan dan retry_mode=standard masuk~/.aws/config, SDK menggunakan mode adaptif.

Language-specific konfigurasi

Pengaturan lintas SDK yang dijelaskan di halaman ini (retry_modedanmax_attempts) berfungsi di semua SDK. Namun, API untuk mengonfigurasi percobaan ulang dalam kode bervariasi menurut bahasa. Lihat panduan pengembang SDK Anda untuk opsi konfigurasi khusus bahasa seperti strategi mundur khusus, kesalahan tambahan yang dapat dicoba ulang, dan penyetelan kuota coba lagi.

Cara kerja percobaan ulang

Bagian ini menjelaskan cara AWS SDK menangani permintaan yang gagal: kesalahan mana yang memicu percobaan ulang, berapa lama SDK menunggu di antara upaya, dan kapan SDK berhenti mencoba lagi.

Apa yang terjadi ketika permintaan gagal

Saat Anda membuat panggilan API melalui AWS SDK, SDK mengikuti urutan ini:

SDK mengulangi loop ini sampai permintaan berhasil, jumlah upaya maksimum tercapai, kuota percobaan ulang habis, atau terjadi kesalahan yang tidak dapat dicoba ulang. Seluruh proses otomatis. Aplikasi Anda melihat respons yang berhasil atau kesalahan akhir.

Kesalahan mana yang dicoba ulang

SDK mengklasifikasikan setiap permintaan yang gagal menjadi salah satu dari tiga kategori: sementara, throttling, atau tidak dapat dicoba ulang. Klasifikasi ini menentukan apakah SDK mencoba kembali permintaan dan berapa lama menunggu sebelum mencoba lagi.

Klasifikasi didasarkan pada kode kesalahan dan kode status HTTP dalam respons layanan. Misalnya, HTTP 400 dengan kode kesalahan diklasifik RequestTimeout asikan sebagai transien dan dicoba ulang. HTTP 400 dengan diklasifik ValidationException asikan sebagai tidak dapat dicoba ulang dan segera dikembalikan.

Klasifikasi kesalahan

Kesalahan transien dicoba ulang dengan penundaan dasar pendek (50 ms):

Kesalahan throttling dicoba lagi dengan penundaan dasar yang lebih lama (1.000 ms):

Non-retryable kesalahan (sepertiAccessDeniedException,ValidationException,ResourceNotFoundException) dikembalikan ke kode Anda segera.

Kesalahan throttling berarti layanan secara aktif menolak permintaan Anda karena batas tarif, sehingga SDK menunggu lebih lama sebelum mencoba lagi untuk memberikan waktu layanan untuk memulihkan kapasitas. Lihat Berapa lama SDK menunggu untuk penundaan spesifik.

Berapa lama SDK menunggu

SDK menggunakan backoff eksponensial dengan jitter penuh. Rata-rata, setiap percobaan ulang menunggu lebih lama dari yang terakhir, dengan pengacakan untuk menyebarkan permintaan dari beberapa klien.

Penundaan dasar berdasarkan jenis kesalahan

Penundaan dasar tergantung pada apakah kesalahannya bersifat sementara atau pelambatan:

Rumus Backoff

SDK menghitung setiap penundaan percobaan ulang menggunakan rumus ini:

delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)

Di mana:

Batas backoff maksimum adalah 20 detik. Tidak ada penundaan individu yang melebihi 20 detik terlepas dari berapa banyak upaya yang telah terjadi.

Contoh yang berhasil

Contoh 1: Kesalahan sementara, 3 upaya maksimal

Total latensi tambahan rata-rata sekitar 75 ms di kedua percobaan ulang.

Contoh 2: Kesalahan throttling, 3 upaya maksimal

Total latensi tambahan rata-rata sekitar 1.500 ms di kedua percobaan ulang.

Contoh 3: Kesalahan sementara, menekan tutup mundur

Dengan penundaan dasar 50 ms, penundaan yang dihitung sebelum pembatasan adalah:

Batasan berlaku pada percobaan ulang ke-10 (upaya ke-11) untuk kesalahan sementara. Untuk kesalahan pelambatan dengan basis 1.000 ms, tutup berlaku pada percobaan ulang ke-6.

Mengapa jitter penting

Pengganda acak disebut jitter penuh. Tanpa itu, semua klien yang mengalami kesalahan pada saat yang sama akan mencoba lagi pada saat yang sama, menciptakan ledakan lalu lintas coba lagi (masalah “kawanan gemuruh”). Jitter penuh menyebarkan percobaan ulang secara seragam di seluruh jendela backoff sehingga layanan menerima tetesan permintaan yang stabil alih-alih lonjakan yang disinkronkan.

Misalnya, 1.000 klien semuanya menerima 503 pada saat yang sama. Jitter penuh mendistribusikan percobaan ulang pertama mereka secara seragam di jendela 50 ms alih-alih mencoba kembali 1.000 kali tepat pada 50 ms.

Server-directed waktu coba lagi

Beberapa Layanan AWS menyertakan x-amz-retry-after header dalam respons kesalahan. Nilai header adalah penundaan dalam milidetik. Ketika header ini ada, SDK menggunakan penundaan yang ditentukan server, dijepit ke minimum penundaan backoff yang dihitung dan maksimum penundaan backoff yang dihitung ditambah 5.000 ms. Karena backoff yang dihitung itu sendiri dibatasi pada 20 detik, penundaan yang diarahkan server maksimum efektif adalah 25 detik. SDK tidak menerapkan jitter ke nilai ini, karena layanan diharapkan untuk mengguncangnya. Hal ini memungkinkan layanan untuk berkomunikasi tepat ketika diharapkan memiliki kapasitas yang tersedia.

Kuota coba lagi (bucket token)

SDK mempertahankan anggaran token internal yang melacak rasio permintaan yang berhasil terhadap kegagalan. Ketika kegagalan tersebar luas, anggaran habis dan SDK mengembalikan kesalahan secara langsung. Aplikasi Anda gagal dengan cepat alih-alih menunggu percobaan ulang yang tidak mungkin berhasil. Ini juga mengurangi lalu lintas coba ulang, membantu gangguan layanan diselesaikan lebih cepat.

Cara kerja kuota coba ulang

Anggaran token mulai penuh. Setiap upaya coba lagi mengurangi token. Ketika percobaan ulang berhasil, SDK mengembalikan token yang dikonsumsi oleh percobaan ulang tersebut. Ketika permintaan berhasil pada percobaan pertama (tidak diperlukan percobaan ulang), SDK mengembalikan 1 token. Ketika anggaran mencapai nol, SDK berhenti mencoba lagi dan mengembalikan kesalahan langsung ke kode Anda.

Biaya yang lebih tinggi untuk percobaan ulang sementara mencerminkan pola kegagalan yang berbeda. Kesalahan sementara seperti 500 detik dan kegagalan koneksi sering menunjukkan masalah di seluruh layanan. Dalam situasi ini, percobaan ulang yang berkelanjutan tidak mungkin berhasil. Ini menambahkan latensi pada panggilan Anda, mengikat sumber daya klien, dan dapat menunda pemulihan untuk semua orang. Kesalahan throttling menandakan bahwa layanan membutuhkan lebih banyak waktu sebelum permintaan dapat berhasil. SDK menunggu lebih lama di antara percobaan ulang untuk meningkatkan kemungkinan keberhasilan.

Kapan blok kuota dicoba lagi

Kuota coba ulang melacak token setiap saat, tetapi hanya memblokir percobaan ulang saat anggaran habis. Selama operasi normal, hampir semua permintaan berhasil dan anggaran tetap penuh. Kuota tidak memiliki efek yang dapat diamati pada percobaan ulang.

Coba ulang yang berhasil mengembalikan hanya biaya tokennya sendiri (14 atau 5 token), bukan biaya percobaan ulang sebelumnya yang gagal dalam permintaan yang sama. Misalnya, jika percobaan ulang pertama gagal dan yang kedua berhasil, anggaran kehilangan 14 token bersih. Anggaran terkuras paling cepat ketika percobaan ulang menghabiskan semua upaya tanpa berhasil, tetapi juga habis secara bertahap ketika permintaan membutuhkan beberapa percobaan ulang sebelum berhasil.

Dengan default 3 upaya maksimal, kuota mulai habis ketika lebih dari sekitar 22% permintaan mengakibatkan kegagalan sementara yang berkelanjutan, atau lebih dari sekitar 32% untuk kesalahan pelambatan. Di bawah tarif ini, permintaan yang berhasil mengisi kembali anggaran lebih cepat daripada percobaan ulang yang gagal mengurasnya.

Saldo awal anggaran sebesar 500 token menyediakan buffer yang menyerap ledakan kegagalan singkat. Lonjakan kesalahan singkat, bahkan yang parah, tidak memblokir percobaan ulang kecuali bertahan cukup lama untuk menguras buffer.

Implikasi praktis

Service-specific perilaku

DynamoDB

Klien DynamoDB menggunakan default yang disetel yang dioptimalkan untuk profil latensi rendah DynamoDB:

Default ini berlaku untuk Amazon DynamoDB dan DynamoDB Streams.

Long-polling operasi

AWS Operasi tertentu menggunakan polling panjang. Mereka dapat menahan koneksi terbuka menunggu pekerjaan tiba. Operasi ini menerima perlakuan coba ulang khusus:

Perilaku khusus: Ketika kuota percobaan ulang habis dan percobaan ulang diblokir (langkah 7 masukApa yang terjadi ketika permintaan gagal), SDK masih menerapkan penundaan mundur sebelum mengembalikan kesalahan ke kode Anda.

Ini penting karena operasi polling panjang biasanya disebut dalam loop ketat. Kode Anda memanggilReceiveMessage, memproses pesan apa pun, lalu segera menelep ReceiveMessage on lagi. Tanpa mundur paksa, anggaran token yang habis akan menyebabkan SDK mengembalikan kesalahan tanpa penundaan. Polling loop Anda kemudian akan segera mengirim permintaan berikutnya, meningkatkan penggunaan CPU klien dan menghasilkan lalu lintas tambahan. Penundaan mundur paksa memutus siklus ini, menjaga penggunaan sumber daya klien dan tingkat polling dapat dikelola selama kegagalan.

Dukungan oleh AWS SDK dan alat

Tabel berikut mencantumkan ketersediaan perilaku coba ulang yang diperbarui di setiap SDK. Untuk SDK-specific detail termasuk versi minimum, default sebelum dan sesudah, dan contoh kode, lihat masalah pelacakan. GitHub