Temu duga umum: Bagaimanakah HTTP 429 dan Retry-After sepatutnya membimbing percubaan semula (retry) klien?

Gesaan dan konteks

Sesuatu API mengembalikan 429 Too Many Requests selepas berlakunya lonjakan trafik. Terangkan sempadan tanggungjawab kod status ini, cara membaca Retry-After, permintaan mana yang boleh dicuba semula, dan cara menghalang klien daripada mengubah beban lampau menjadi kegagalan melata (cascading failure).

Perkara yang dinilai oleh penemu duga

Memahami 429 sebagai isyarat had kadar dan bukannya kegagalan pelayan yang kekal.
Mengendalikan kedua-dua format Retry-After dan situasi ketiadaan pengepala dengan betul.
Menggabungkan keidempotenan, tarikh akhir (deadline), dan kesan sampingan perniagaan apabila memutuskan untuk mencuba semula.
Melindungi perkhidmatan dengan backoff eksponen, jitter, bajet, dan kawalan kadar.

Soalan untuk dijelaskan sebelum menjawab

Adakah had tersebut bagi setiap pengguna, token, penyewa (tenant), IP, atau sumber kongsi?
Adakah respons mengandungi Retry-After, dan bolehkah klien mempercayai jamnya?
Adakah kaedah dan operasi perniagaan bersifat idempoten, atau adakah terdapat kunci keidempotenan (idempotency key)?
Adakah terdapat tarikh akhir keseluruhan, had percubaan semula, dan bajet percubaan semula (retry budget)?
Adakah perkhidmatan mendedahkan kuota, baki kapasiti, atau ID permintaan?

Rangka jawapan 30 saat

Saya menganggap 429 sebagai maklum balas had kadar dan membaca Retry-After, yang boleh berupa saat atau tarikh HTTP. Saya mematuhi nasihat pelayan dalam lingkungan had backoff klien yang selamat dan menambah jitter. Saya hanya mencuba semula secara automatik untuk operasi idempoten atau operasi yang dilindungi oleh kunci keidempotenan, dengan had tarikh akhir, percubaan, dan bajet. Tanpa Retry-After, saya menggunakan backoff eksponen dengan jitter; 429 yang berulang akan berhenti dan mengembalikan kawalan kepada pemanggil.

Huraian mendalam langkah demi langkah

Langkah 1: Sahkan semantik 429

RFC 6585 mentakrifkan 429 untuk permintaan yang terlalu banyak dalam tempoh masa tertentu dan membenarkan Retry-After. Ia memberitahu klien untuk mengurangkan kadar; ia tidak sepatutnya dianggap seperti 500 dan dicuba semula serta-merta.

Langkah 2: Huraikan Retry-After

Retry-After boleh berupa integer saat bukan negatif atau tarikh HTTP. Bagi tarikh, gunakan Date respons atau jam yang dipercayai untuk menganggarkan kelewatan, dan hadkan nilai negatif, terlalu besar, atau tidak sah.

text

Retry-After: 8
Retry-After: Wed, 02 Aug 2026 02:00:00 GMT

Langkah 3: Tentukan sama ada penghantaran semula adalah selamat

Kaedah selamat seperti GET dan HEAD biasanya boleh dicuba semula. Operasi tulis memerlukan semantik idempoten, kunci keidempotenan, atau penyahduplikasian di pihak pelayan. Kaedah yang sama sekalipun boleh mendatangkan kesan sampingan seperti mengenakan caj, menghantar e-mel, atau mencipta tugasan.

Langkah 4: Kira kelewatan dan backoff

Patuhi Retry-After terlebih dahulu, kemudian gunakan had atas backoff eksponen klien dan jitter rawak. Jitter menghalang banyak klien daripada bangun pada masa yang sama. Masa menunggu mesti muat dalam tarikh akhir permintaan dan bukannya memanjangkannya tanpa henti.

Langkah 5: Hadkan amplifikasi percubaan semula

Tetapkan percubaan bagi setiap permintaan, bajet percubaan semula global, dan had keserentakan. Kurangkan kadar bagi sumber yang terus mengembalikan 429; gunakan baris gilir tempatan atau pemutus litar (circuit breaker) apabila perlu supaya percubaan semula tidak menggunakan kapasiti trafik normal.

Langkah 6: Asingkan tanggungjawab klien dan pelayan

Pelayan menyediakan isyarat had yang jelas dan medan yang boleh diperhatikan. Klien menghormati isyarat tersebut, berundur (back off), dan berhenti. Selepas pemulihan, tingkatkan trafik secara beransur-ansur dan bukannya melepaskan semua permintaan yang sedang menunggu secara serentak.

Langkah 7: Rekod keputusan dan buat penambahbaikan

Jejak kadar 429, taburan Retry-After, kadar kejayaan akhir, bilangan percubaan semula, dan penamatan akibat tarikh akhir. Gunakan data tersebut untuk melaraskan kuota, bajet klien, dan amaran dan bukannya menganggap 429 sebagai kegagalan satu permintaan semata-mata.

Contoh jawapan berkualiti tinggi

Mula-mula saya akan mengesahkan dimensi had dan pengepala respons. Dengan Retry-After: 8, klien menunggu sekurang-kurangnya lapan saat; dengan tarikh HTTP, ia mengira kelewatan menggunakan jam yang dipercayai dan had maksimum. Carian pesanan dengan kunci keidempotenan boleh dicuba semula secara automatik, manakala penciptaan caj tanpa penyahduplikasian mesti disahkan oleh lapisan perniagaan. Saya menggunakan backoff eksponen dengan jitter rawak, had tiga percubaan bagi setiap permintaan, bajet percubaan semula global, dan tarikh akhir keseluruhan. Respons 429 yang berterusan akan merendahkan keserentakan dan menjeda baris gilir supaya percubaan semula tidak memburukkan beban lampau. Metrik merangkumi kadar 429, masa menunggu, dan kadar kejayaan akhir untuk pelarasan kuota dan amaran.

Kesilapan lazim

Menganggap 429 seperti 500 dan mencuba semula serta-merta dalam gelung yang ketat.
Hanya menyokong Retry-After dalam bentuk integer dan mengabaikan bentuk tarikh HTTP.
Gagal membezakan bacaan idempoten daripada operasi tulis yang mempunyai kesan sampingan.
Mengabaikan tarikh akhir, bajet, atau had keserentakan sehingga percubaan semula bertambah tanpa kawalan.
Memberikan kelewatan tetap yang sama kepada setiap klien dan mencetuskan lonjakan percubaan semula yang serentak.

Soalan susulan dan respons

Soalan susulan 1: Berapa lama anda perlu menunggu tanpa Retry-After?

Gunakan backoff eksponen dengan jitter berserta had kelewatan maksimum, percubaan, dan jumlah tarikh akhir. Laraskannya daripada kadar 429 dan kuota dan bukannya memilih satu pemalar kekal.

Soalan susulan 2: Bagaimana jika tarikh HTTP telah berlalu?

Anggap kelewatan pelayan sebagai sifar tetapi tetap gunakan backoff tempatan dan jitter, serta rekodkan isu jam atau penjanaan pelayan. Jangan lancarkan percubaan semula berkeserentakan tinggi semata-mata kerana tarikh tersebut tidak sah.

Soalan susulan 3: Bolehkah POST dicuba semula?

Hanya apabila API mentakrifkan keidempotenan, menyediakan kunci keidempotenan, atau lapisan perniagaan boleh melakukan penyahduplikasian. Jika tidak, kembalikan kepada pemanggil untuk keputusan penghantaran semula yang jelas.

Soalan susulan 4: Bagaimana jika banyak instans berkongsi satu kuota?

Selaraskan bajet percubaan semula dan kawalan kadar merentas proses atau pada skop penyewa, menggunakan isyarat kongsi untuk mengurangkan keserentakan. Backoff bagi setiap instans tidak dapat menghalang penggunaan berlebihan secara agregat.

Soalan susulan 5: Bagaimanakah anda mengelakkan satu lagi lonjakan beban lampau semasa pemulihan?

Tingkatkan baris gilir secara beransur-ansur, kekalkan jitter dan had keserentakan, serta tingkatkan kadar hanya selepas memerhatikan 429 dan kependaman. Jangan lepaskan semua permintaan yang menunggu sekali gus.

Soalan susulan 6: Metrik manakah yang membuktikan strategi ini berkesan?

Bandingkan kadar 429, amplifikasi percubaan semula, kadar kejayaan, kependaman P95, penamatan akhir, dan masa pemulihan, yang dibahagikan mengikut penyewa atau sumber.