Had Kelajuan dan Pengurusan Ralat Berdaya tahan

Keuntungan:

• Boleh mentafsir had laju (RPM/ITPM/OTPM) dan ralat 429
• Melaksanakan backoff eksponen dan cuba semula dengan cuba semula selepas
• Mengelaskan dan mengendalikan kod ralat HTTP biasa (400/401/429/500/529) dengan betul

Dalam persekitaran pengeluaran, tiada API bertindak balas dengan sempurna sepanjang masa. Kadangkala anda menghantar permintaan terlalu cepat dan mencapai had; kadangkala pelayan sibuk buat sementara waktu; Kadang-kadang permintaan anda salah dari awal. Apa yang membezakan integrasi yang kukuh daripada percubaan amatur ialah ia mengendalikan situasi ini secara ramalan dan automatik. Dalam unit ini anda akan belajar tentang had kadar (RPM/ITPM/OTPM), ralat 429, cuba semula dengan backoff eksponen dan pengelasan yang betul bagi kod ralat HTTP biasa. Matlamat: untuk membina aliran yang begitu mantap sehingga pengguna tidak akan menyedarinya.

Apakah Had Kelajuan?

Pembekal mengehadkan jumlah kerja yang boleh dilakukan oleh suis dalam tempoh masa tertentu. Perlindungan ini; Ia melindungi kedua-dua infrastruktur dan anda daripada letupan kos yang mendadak. Terdapat tiga jenis had biasa:

• RPM (Permintaan Per Minit): Bilangan permintaan seminit.
• ITPM (Token Input Per Minit): Token input yang boleh diproses seminit.
• OTPM (Token Output Per Minute): Token output yang boleh dihasilkan seminit.

Jika anda melebihi mana-mana had ini, pembekal menolak permintaan dan mengembalikan kod ralat 429. Had biasanya berbeza-beza bergantung pada tahap akaun anda (peringkat) dan mungkin meningkat dari semasa ke semasa.

Petua: Anda boleh menonton apabila anda menghampiri had daripada pengepala respons. Kebanyakan pembekal melaporkan baki kuota anda dengan pengepala seperti x-ratelimit-remaining-*. Memantau nilai ini dan mendikit lalu lintas di hadapan adalah cara paling matang untuk mencegah masalah tanpa mendapat 429.

429 dan Pengesanan Semula Eksponen

429 (had kadar) ialah ralat sementara dan boleh dicuba semula. Jawapan yang betul ialah menunggu permintaan untuk seketika dan cuba lagi. Tetapi menunggu berterusan tidak mencukupi; Jika semua orang mencuba sekali lagi pada masa yang sama, had akan dicapai semula. Penyelesaiannya ialah mundur eksponen: meningkatkan masa menunggu secara eksponen dengan setiap percubaan yang gagal.

# Percubaan logik mundur eksponen 1 → 429 → tunggu 1 saat percubaan 2 → 429 → tunggu 2 saat percubaan 3 → 429 → tunggu 4 saat percubaan 4 → 429 → tunggu 8 saat (+ rawak kecil "jitter")... berputus asa dan laporkan selepas paling banyak N percubaan

Menambahkan sedikit rawak (jitter) pada ini menghalang permintaan bertembung apabila cuba mencuba semula pada masa yang sama. Selain itu, respons 429 sering membawa pengepala `cuba semula selepas`: "cuba lagi dalam beberapa saat ini". Menghormati gelaran ini lebih tepat daripada menunggu membuta tuli.

Awas: Apabila anda mendapat 429, "memaksanya dengan menghantar lebih banyak permintaan" akan memburukkan keadaan; Had terus diisi dan tiada permintaan diteruskan. Tindak balas yang betul ialah berundur, bukan pecutan. Berita baik: kebanyakan SDK rasmi secara automatik mencuba semula 429 dan ralat pelayan dengan mundur — gunakan tingkah laku SDK ini sebelum memasangnya secara manual.

Mengelaskan Kod Ralat HTTP

Tidak setiap kesilapan adalah sama. Perbezaan kritikal: bolehkah ia dicuba semula atau adakah ia permintaan/isu identiti?

Kod

Maknanya

Boleh cuba lagi?

respons yang betul

400

Permintaan tidak sah (ralat format/parameter)

tidak

Betulkan permintaan; jangan hantar yang sama lagi

401

Ralat pengesahan (kunci tidak sah/tiada)

tidak

Betulkan kunci/tajuk

403

Tiada kebenaran (tiada akses kepada model/ciri)

tidak

Semak kebenaran/skop

404

Tidak Ditemui (ID model/titik akhir tidak betul)

tidak

ID/alamat model yang betul

429

Had laju melebihi

ya

Berundur + cuba semula selepas

500

Ralat pelayan

ya

Cuba lagi dengan berundur

529

Pelayan terlebih muatan

ya

Cuba lagi dengan berundur

Peraturan emas: 429, 500 dan 529 adalah sementara; Ia dicuba sekali lagi dengan pengeluaran. 400, 401, 403, 404 adalah isu permintaan/identiti; Mencuba sekali lagi tidak akan menyelesaikannya, dan ia membazirkan usaha. Kod anda mesti membezakan antara kedua-dua kumpulan ini.

Langkah demi Langkah: Panggilan Tahan Lama

1. Hantar permintaan. Jika berjaya, teruskan.
2. Kelaskan kod ralat. Boleh cuba lagi?
3. Jika boleh dicuba: ikuti cuba semula selepas, gunakan pengunduran eksponen + jitter, cuba beberapa kali terhad (cth. 5 maks).
4. Jika tidak cuba: Betulkan (format/kunci) dan hentikan; Jangan ulangi permintaan salah yang sama dalam gelung.
5. Pertimbangkan untuk menyerah. Jika masih tidak berjaya selepas n percubaan, tunjukkan mesej sopan kepada pengguna dan log peristiwa (unit penjejakan 11).

# Panggilan mantap pseudo-codedene = 0repeat: response = request_at() if response.success: return response if response.code in [429, 500, 529] dan cuba < 5: wait = retry_after ?? (2^try sec + jitter) tidur(tunggu); cuba += 1; git semula jika response.code dalam [400, 401, 403, 404]: save_error(response); pulangkan "permintaan mesti diperbaiki" pulangkan "ralat kekal, cuba kemudian"

# Maklum balas yang sopan kepada pengguna (apabila percubaan semula telah habis) "Saya sedang sibuk sekarang, saya tidak dapat memproses permintaan anda. Cuba sebentar lagi, atau saya telah menyimpan permintaan anda, saya akan menghubungi anda semula apabila permintaan anda sudah sedia."

Gesaan lemah / Gesaan kuat (di sini: reka bentuk mesej ralat)

# LEMAH (memaparkan ralat mentah kepada pengguna)"Ralat 429: rate_limit_error"

# STRONG (mesra pengguna, meyakinkan, mencadangkan tindakan) "Terdapat kesesakan sementara dalam sistem. Kami telah menerima permintaan anda dengan selamat dan ia sedang dicuba semula secara automatik. Jika hasil tidak muncul dalam beberapa saat, anda boleh memuat semula halaman."

Mendedahkan ralat teknikal mentah kepada pengguna akhir kedua-duanya menjejaskan kepercayaan dan boleh menjadi kelemahan keselamatan. Kategorikan ralat secara dalaman dan berikan pengguna mesej yang tenang dan berorientasikan tindakan; hanya tulis butiran teknikal untuk rekod.

Tiga Kes Mini

Kes 1 — Bot terhempas dalam letupan lalu lintas. Bot perkhidmatan pelanggan menerima 429 trafik lonjakan pada hari kempen; Tiada percubaan semula dalam kod, setiap ralat ditunjukkan terus kepada pengguna sebagai "ralat". Mereka menambah anjakan eksponen + cuba semula selepas; dengan trafik yang sama, permintaan diluluskan dengan kelewatan beberapa saat, pengguna tidak melihat sebarang ralat.

Kes 2 — Mencuba 400 dalam gelung. Penyepaduan mendapat 404 disebabkan ID model yang tidak sah, tetapi menganggap semua ralat sebagai "sementara" dan mencuba lagi dalam gelung tak terhingga; Log menjadi bengkak dan beban yang tidak perlu dibuat. Mereka menambah klasifikasi ralat: 404 dianggap kekal, gelung dihentikan dan ID model diperbetulkan. Pengajaran: jangan cuba setiap kesilapan lagi.

Kes 3 — Menguruskan had dari hadapan. Kerja pengayaan data sentiasa berjalan pada had 429. Mereka mengikuti pengepala x-ratelimit-baki dan mendikit trafik mengikut kuota. Jadi mereka mengekalkan rentak yang stabil tepat di bawah had, tanpa mengambil sebarang 429s; Kerja itu dilakukan dengan lebih mudah dijangka dan lebih cepat.

Kesilapan biasa

• Meningkatkan kelajuan dalam 429: Memburukkan keadaan; Beralih untuk berundur.
• Mencuba semula setiap ralat: 400/401/404 adalah kekal; Mencuba lagi adalah satu pembaziran.
• Menggunakan tunggu tetap: Mencipta perlanggaran; Gunakan eksponen + jitter.
• Mengabaikan 'cuba semula selepas': Adalah paling tepat untuk mematuhi masa yang ditentukan oleh pembekal.
• Mendedahkan ralat mentah kepada pengguna: Menggoncang kepercayaan, mewujudkan kelemahan; Kelaskan di dalam.
• Percubaan semula tanpa had: Tetapkan had atas (cth. 5 percubaan semula); kemudian berputus asa dengan anggun.

Lebih Dalam: Beratur, Konkurensi dan Pemutus Litar

Ketahanan satu keinginan adalah langkah pertama; Kematangan sebenar adalah untuk menguruskan sejumlah besar permintaan tanpa mencapai had. Tiga konsep mula dimainkan di sini.

Baris gilir: Anda meletakkan permintaan dalam baris gilir untuk menghantarnya pada kadar terkawal dan bukannya serta-merta. Beratur melancarkan trafik yang mendadak: Walaupun 1,000 permintaan tiba serentak, baris gilir akan melepaskannya pada kadar di bawah had. Dengan cara ini anda menghalang 429, maka anda tidak perlu risau untuk membetulkannya.

Had konkurensi: Anda mengehadkan bilangan permintaan "di udara" pada masa yang sama. Permintaan selari tanpa had dengan cepat mengisi had RPM dan TPM. Siling serentak yang munasabah (mis. tidak lebih daripada 10 permintaan serentak) kedua-duanya mengekalkan had dan menjadikan sistem boleh diramal.

Pemutus litar: Jika pembekal terus memulangkan 500/529, bukannya mencuba setiap permintaan dengan bersungguh-sungguh, anda "memutuskan litar" untuk seketika dan dengan cepat gagal permintaan itu tanpa menghantarnya. Selepas menunggu, anda menghidupkan semula litar dan cuba. Corak ini menghalang sistem anda daripada ranap sekiranya berlaku kegagalan pembekal sementara.

Bersama-sama, ketiga-tiga ini mewujudkan daya tahan peringkat sistem di luar logik cuba semula satu panggilan. Pada skala kecil, percubaan semula automatik SDK adalah mencukupi; Apabila skala semakin meningkat, giliran, konkurensi, dan pemutus litar menjadi sangat diperlukan. Kesemuanya mempunyai matlamat yang sama: untuk menggambarkan masalah sementara kepada pengguna bukan sebagai ranap, tetapi sebagai kelewatan yang tidak dapat dilihat selama beberapa saat.

Secara ringkasnya

429 kembali apabila had laju (RPM/ITPM/OTPM) melebihi; Ini adalah ralat sementara dan akan dicuba semula menggunakan retry-after dan backoff eksponen + jitter. 500 dan 529 juga adalah sementara; 400/401/403/404 ialah permintaan/isu identiti dan tidak boleh diselesaikan dengan mencuba lagi. Aliran yang mantap memisahkan ralat kepada dua kumpulan ini, mencuba beberapa kali terhad, memantau had dari hadapan dan menunjukkan mesej yang tenang kepada pengguna.

Tugasan permohonan

Pertimbangkan integrasi anda. (1) Senaraikan kod ralat yang mungkin anda hadapi dan pisahkan mereka kepada "boleh dicuba semula / kekal". (2) Tulis pelan penarikan semula eksponen anda (pegangan awal, pekali, topi, jitter). (3) Tentukan cara menggunakan pengepala cuba semula selepas. (4) Tulis mesej sopan untuk dipaparkan kepada pengguna apabila percubaan semula telah habis.

senarai semak

• [ ] Saya boleh menerangkan had RPM/ITPM/OTPM dan 429.
• [ ] Saya boleh menggunakan logik pengunduran eksponen + jitter + cuba semula selepas.
• [ ] Saya boleh mengklasifikasikan kod ralat sebagai boleh cuba semula/kekal.
• [ ] Saya tahu bahawa kita tidak sepatutnya mencuba setiap kesilapan.
• [ ] Daripada ralat mentah, saya boleh menunjukkan kepada pengguna mesej yang tenang dan berorientasikan tindakan.