Gesaan dan skop
Ini menguji sempadan protokol bagi pengehadan kadar (rate limiting), bukan sekadar pembilang Redis. RFC 6585 mentakrifkan 429 untuk terlalu banyak permintaan dalam satu tempoh dan membenarkan Retry-After; RFC 9110 mentakrifkan saat dan tarikh HTTP. Tukarkan semantik tersebut kepada tingkah laku yang boleh dilaksanakan oleh klien dengan selamat.
Perkara yang dinilai oleh penemu duga
- Kunci had, tetingkap, kuota dan medan respons yang menerangkan siapa yang dihadkan dan bila pemulihan boleh dilakukan.
- Badan 429 yang konsisten, Retry-After, ID permintaan dan butiran kuota yang selamat.
- Penghuraian saat atau tarikh oleh klien, jitter, batas masa (deadlines) dan belanjawan percubaan (attempt budgets).
- Sempadan percubaan semula untuk operasi tulis bukan idempoten, kerja tak segerak (asynchronous) dan masa tamat rangkaian.
- Metrik untuk kekerapan mencapai had, masa pemulihan, amplifikasi percubaan semula dan kejayaan akhirnya.
Struktur jawapan yang disyorkan
Takrifkan dimensi had dan kelas ralat. Tunjukkan respons 429 dan peraturan Retry-After. Klien menggunakan pengepala, jenis permintaan dan belanjawan tempatan untuk menunggu, membatalkan atau beralih kepada kerja tak segerak; setiap percubaan semula menggunakan backoff eksponen terhad (capped) dengan jitter. Akhiri dengan tanggungjawab get laluan (gateway), aplikasi, SDK dan operasi perniagaan serta ujian suntikan kerosakan (fault-injection).
Analisis mendalam: daripada respons kepada percubaan semula
Jadikan had boleh dijelaskan
Kuncikan had mengikut penyewa, kelayakan, IP, titik akhir atau sumber global. Kembalikan jenis ralat yang stabil, ID permintaan dan sebab yang selamat. Jika beberapa pengehad dicetuskan, gunakan masa menunggu terpanjang yang diketahui tanpa mendedahkan kuota penyewa lain.
Hasilkan Retry-After dengan betul
Kelewatan bermaksud sekurang-kurangnya berapa saat perlu menunggu; tarikh HTTP bermaksud masa pemulihan. Kira tetingkap dalaman dengan jam monotonik, bundarkan ke atas dan hadkan nilainya. Klien masih memerlukan masa menunggu minimum dan jitter kerana tarikh boleh dipengaruhi oleh perbezaan jam (clock skew) atau proksi.
Hurai dan lakukan backoff pada klien
Utamakan Retry-After terlebih dahulu; jika ia tiada atau tidak sah, gunakan backoff eksponen terhad. Berikan setiap permintaan logik jumlah batas masa dan belanjawan percubaan. Selaraskan kerja serentak melalui giliran kongsi atau belanjawan token supaya banyak tugas tidak bangkit serentak.
Hormati sempadan kedap kuasa (idempotency)
GET, HEAD dan PUT atau DELETE yang jelas idempoten biasanya boleh dicuba semula. POST memerlukan kunci kedap kuasa dan semantik pelayan yang sepadan. Jika respons hilang selepas pelaksanaan, buat pertanyaan status atau guna semula kunci yang sama dan bukannya mencipta kesan sampingan kedua.
Perhatikan pemulihan, bukan sekadar ralat
Catatkan dimensi had, bilangan 429, taburan Retry-After, masa menunggu klien, amplifikasi percubaan semula, kejayaan akhirnya dan pembatalan. Segmentasikan mengikut versi SDK dan penyewa untuk membezakan percubaan semula serta-merta daripada pertumbuhan trafik yang sah.
Contoh jawapan
"Saya akan mengehadkan kadar mengikut penyewa, kelayakan dan titik akhir serta mengembalikan jenis ralat yang stabil, ID permintaan, sebab yang selamat dan Retry-After. Pelayan mengira kelewatan tetingkap monotonik, membundarkannya ke atas dan mengehadkannya. SDK menghurai Retry-After terlebih dahulu dan selain itu menggunakan backoff eksponen dengan jitter; setiap permintaan logik mempunyai batas masa dan had percubaan. GET boleh dicuba semula; POST memerlukan kunci kedap kuasa atau pertanyaan status. Saya akan memantau 429, taburan menunggu, amplifikasi percubaan semula, kejayaan akhirnya dan pembatalan, kemudian menjalankan ujian berbilang klien yang disegerakkan untuk mengesahkan pemulihan yang lancar."
Mod kegagalan biasa dan pembaikan
- Mencuba semula setiap kegagalan → Kelaskan mengikut status, semantik kaedah dan jenis ralat.
- Mengabaikan format Retry-After → Sokong format saat dan tarikh HTTP serta tolak nilai tidak sah dengan selamat.
- Percubaan semula serta-merta bagi setiap benang (thread) → Kongsi belanjawan, giliran dan jitter.
- Menganggap POST adalah idempoten → Gunakan kunci kedap kuasa, pertanyaan status atau hasil eksplisit tanpa percubaan semula.
- Hanya memerhatikan bilangan 429 → Ukur masa menunggu, amplifikasi, kejayaan akhirnya dan pembatalan.
Rubrik pemarkahan dan semakan kendiri
Jawapan yang kukuh merangkumi kunci had, semantik 429, penghasilan dan penghuraian Retry-After, backoff dengan jitter, batas masa, kedap kuasa, penyelarasan keserentakan, butiran kuota yang selamat, pemilikan komponen dan metrik pengesahan.
Tanya diri anda: Adakah klien tahu bila pemulihan boleh berlaku? Bagaimana jika jam berbeza? Bagaimana jika pengepala tiada? Bolehkah percubaan semula menduplikasi kesan? Bagaimanakah tugas serentak disebarkan? Apakah yang membuktikan pemulihan bertambah baik?
Soalan susulan dan lanjutan
Patutkah Retry-After menggunakan saat atau tarikh?
Kedua-duanya adalah bentuk HTTP yang sah. Saat sesuai untuk tetingkap pendek dan mengelakkan perbezaan jam; tarikh boleh menyatakan titik pemulihan yang diketahui. Pastikan output pelayan konsisten sambil menjadikan penghuraian SDK serasi dengan kedua-duanya dan mengendalikan nilai yang telah tamat tempoh.
Jika kedua-dua get laluan dan aplikasi mengehadkan, masa menunggu yang manakah dikembalikan?
Masa menunggu yang dapat dilihat oleh klien harus meliputi semua had yang diketahui, biasanya yang paling lama, bersama ID permintaan. Telemetri dalaman merekodkan setiap lapisan supaya penolakan get laluan tidak tersilap dikaitkan dengan aplikasi.
Bolehkah klien mencuba semula tanpa Retry-After?
Hanya apabila kaedah dan semantik ralat membenarkannya, batas masa masih berbaki dan belanjawan backoff tempatan mencukupi. Gunakan backoff terhad dengan jitter; untuk operasi tulis yang tidak boleh dicuba semula, kembalikan status yang boleh ditanya atau kegagalan yang eksplisit.
Bagaimanakah anda menguji ribut percubaan semula (retry storm)?
Segerakkan banyak klien untuk mencetuskan 429, kemudian suntik pengepala tidak sah, perbezaan jam (clock skew), masa tamat sambungan dan jitter pemulihan. Perhatikan keluk ketibaan, amplifikasi, masa pemulihan dan kejayaan akhirnya.