Keuntungan:
- Dapat mengartikan batas kecepatan (RPM/ITPM/OTPM) dan 429 error
- Menerapkan backoff eksponensial dan coba lagi dengan coba lagi setelahnya
- Mengklasifikasikan dan menangani kode kesalahan HTTP umum dengan benar (400/401/429/500/529)
Dalam lingkungan produksi, tidak ada API yang selalu merespons dengan sempurna. Terkadang Anda mengirim permintaan terlalu cepat dan mencapai batasnya; terkadang server sedang sibuk untuk sementara; Terkadang permintaan Anda salah sejak awal. Apa yang membedakan integrasi solid dari upaya amatir adalah bahwa integrasi ini menangani situasi ini secara prediktif dan otomatis. Dalam unit ini Anda akan mempelajari tentang batas kecepatan (RPM/ITPM/OTPM), kesalahan 429, percobaan ulang dengan backoff eksponensial, dan klasifikasi yang tepat dari kode kesalahan HTTP umum. Tujuannya: untuk membangun aliran yang begitu kuat sehingga pengguna tidak akan pernah menyadarinya.
Apa itu Batas Kecepatan?
Penyedia membatasi seberapa banyak pekerjaan yang dapat dilakukan sebuah switch dalam jangka waktu tertentu. Perlindungan ini; Ini melindungi infrastruktur dan Anda dari ledakan biaya yang tiba-tiba. Ada tiga jenis batasan yang umum:
- RPM (Permintaan Per Menit): Jumlah permintaan per menit.
- ITPM (Input Token Per Minute): Input token yang dapat diproses per menit.
- OTPM (Output Tokens Per Minute): Output token yang dapat dihasilkan per menit.
Jika Anda melebihi batas ini, penyedia akan menolak permintaan tersebut dan mengembalikan kode kesalahan 429. Batasan umumnya bervariasi tergantung pada level akun Anda (tingkatan) dan dapat ditingkatkan seiring waktu.
Tip: Anda dapat melihat ketika Anda mendekati batas dari header respons. Kebanyakan penyedia melaporkan sisa kuota Anda dengan header seperti x-ratelimit-remaining-*. Memantau nilai-nilai ini dan membatasi lalu lintas di depan adalah cara paling matang untuk mencegah masalah tanpa mendapatkan 429.
429 dan Retracement Eksponensial
429 (batas kecepatan) adalah kesalahan sementara dan dapat dicoba lagi. Respons yang benar adalah menunggu permintaan beberapa saat dan coba lagi. Namun menunggu terus-menerus tidaklah cukup; Jika semua orang mencoba lagi pada saat yang sama, batasnya akan tercapai lagi. Solusinya adalah kemunduran eksponensial: meningkatkan waktu tunggu secara eksponensial setiap kali upaya gagal.
# Uji coba logika backoff eksponensial 1 → 429 → tunggu 1 detik uji coba 2 → 429 → tunggu 2 detik uji coba 3 → 429 → tunggu 4 detik uji coba 4 → 429 → tunggu 8 detik (+ "jitter" acak kecil)... menyerah dan lapor setelah paling banyak N uji coba
Menambahkan sedikit keacakan (jitter) untuk mencegah permintaan bertabrakan ketika mencoba mencoba lagi pada saat yang sama. Selain itu, respon 429 sering kali membawa header `retry-after`: "coba lagi dalam beberapa detik ini". Menghargai gelar ini lebih tepat daripada menunggu secara membabi buta.
Perhatian: Saat Anda mendapatkan 429, "memaksanya dengan mengirimkan lebih banyak permintaan" akan memperburuk situasi; Batasnya terus terisi dan tidak ada permintaan yang diproses. Respons yang benar adalah mundur, bukan akselerasi. Kabar baik: sebagian besar SDK resmi secara otomatis mencoba ulang 429 dan kesalahan server dengan backoff — gunakan perilaku SDK ini sebelum menginstalnya secara manual.
Mengklasifikasikan Kode Kesalahan HTTP
Tidak setiap kesalahan itu sama. Perbedaan penting: dapatkah dicoba ulang atau ini masalah permintaan/identitas?
Kode
Artinya
Bisakah dicoba lagi?
respons yang benar
400
Permintaan tidak valid (kesalahan format/parameter)
tidak
Perbaiki permintaan tersebut; jangan kirim hal yang sama lagi
401
Kesalahan autentikasi (kunci tidak valid/hilang)
tidak
Perbaiki kunci/judul
403
Tanpa otorisasi (tidak ada akses ke model/fitur)
tidak
Periksa izin/cakupan
404
Tidak Ditemukan (ID model/titik akhir salah)
tidak
ID/alamat model yang benar
429
Batas kecepatan terlampaui
Ya
Mundur + coba lagi setelahnya
500
Kesalahan server
Ya
Coba lagi dengan mundur
529
Server kelebihan beban
Ya
Coba lagi dengan mundur
Aturan emas: 429, 500 dan 529 bersifat sementara; Ini dicoba lagi dengan penarikan. 400, 401, 403, 404 adalah masalah permintaan/identitas; Mencoba lagi tidak akan menyelesaikan masalah, dan hanya membuang-buang usaha. Kode Anda harus membedakan kedua kelompok ini.
Langkah demi Langkah: Panggilan Tahan Lama
- Kirimkan permintaan. Jika berhasil, lanjutkan.
- Klasifikasikan kode kesalahan. Bisakah dicoba lagi?
- Jika dapat dicoba: ikuti percobaan ulang setelahnya, terapkan backoff eksponensial + jitter, coba beberapa kali (misalnya 5 maks).
- Jika belum dicoba: Perbaiki (format/kunci) dan hentikan; Jangan ulangi permintaan salah yang sama dalam perulangan.
- Pertimbangkan untuk menyerah. Jika masih gagal setelah n kali mencoba, tunjukkan pesan sopan kepada pengguna dan catat kejadian tersebut (unit pelacakan 11).
# Panggilan kuat pseudo-codedene = 0repeat: respon = request_at() if respon.success: kembalikan respon if respon.code di [429, 500, 529] dan coba < 5: tunggu = coba lagi_setelah ?? (2^coba detik + jitter) tidur(tunggu); coba += 1; git lagi jika respon.kode di [400, 401, 403, 404]: save_error(response); kembalikan "permintaan harus diperbaiki" kembalikan "kesalahan permanen, coba lagi nanti"
# Umpan balik yang sopan kepada pengguna (saat percobaan ulang sudah habis) "Saya sedang sibuk saat ini, saya tidak dapat memproses permintaan Anda. Coba lagi nanti, atau saya sudah menyimpan permintaan Anda, saya akan menghubungi Anda kembali jika sudah siap."
Prompt lemah / Prompt kuat (di sini: desain pesan kesalahan)
# LEMAH (menampilkan kesalahan mentah kepada pengguna)"Kesalahan 429: rate_limit_error"
# STRONG (ramah pengguna, meyakinkan, menyarankan tindakan) "Ada kemacetan sementara di sistem. Kami telah menerima permintaan Anda dengan aman dan sedang dicoba lagi secara otomatis. Jika hasilnya tidak muncul dalam beberapa detik, Anda dapat menyegarkan halaman."
Mengungkap kesalahan teknis mentah kepada pengguna akhir dapat merusak kepercayaan dan dapat menjadi kerentanan keamanan. Kategorikan kesalahan secara internal dan berikan pesan yang tenang dan berorientasi pada tindakan kepada pengguna; cukup tulis detail teknis untuk dicatat.
Tiga Kasus Mini
Kasus 1 — Perahu jatuh akibat ledakan lalu lintas. Bot layanan pelanggan menerima lonjakan lalu lintas sebesar 429 pada hari kampanye; Tidak ada percobaan ulang dalam kode, setiap kesalahan tercermin langsung kepada pengguna sebagai "kesalahan". Mereka menambahkan retracement eksponensial + coba lagi setelahnya; dengan lalu lintas yang sama, permintaan diteruskan dengan penundaan beberapa detik, pengguna tidak melihat kesalahan apa pun.
Kasus 2 — Mencoba 400 dalam satu putaran. Integrasi mendapatkan 404 karena ID model tidak valid, tetapi memperlakukan semua kesalahan sebagai "sementara" dan mencoba lagi dalam putaran tak terbatas; Log menjadi bengkak dan beban yang tidak perlu terjadi. Mereka menambahkan klasifikasi kesalahan: 404 dianggap permanen, loop dihentikan dan ID model diperbaiki. Pelajaran: jangan mencoba setiap kesalahan lagi.
Kasus 3 — Mengelola batas dari depan. Pekerjaan pengayaan data terus berjalan pada batas 429. Mereka mengikuti header sisa batas kecepatan x dan membatasi lalu lintas sesuai kuota. Jadi mereka menjaga kecepatan tetap di bawah batas, tanpa melakukan 429 detik; Pekerjaan dilakukan dengan lebih dapat diprediksi dan lebih cepat.
Kesalahan umum
- Meningkatkan kecepatan di 429: Memperburuk situasi; Beralih ke mundur.
- Mencoba kembali setiap kesalahan: 400/401/404 bersifat permanen; Mencoba lagi adalah hal yang sia-sia.
- Menggunakan menunggu tetap: Membuat tabrakan; Gunakan eksponensial + jitter.
- Mengabaikan 'retry-after': Cara paling akurat adalah dengan mematuhi waktu yang ditentukan oleh penyedia.
- Mengungkap kesalahan mentah kepada pengguna: Menggoyahkan kepercayaan, menciptakan kerentanan; Klasifikasikan di dalam.
- Percobaan ulang tanpa batas: Tetapkan batas atas (misalnya 5 percobaan ulang); lalu menyerah dengan anggun.
Lebih Dalam: Antrian, Konkurensi, dan Pemutus Arus
Ketahanan terhadap satu keinginan adalah langkah pertama; Kedewasaan sebenarnya adalah mengelola permintaan dalam jumlah besar tanpa mencapai batas. Tiga konsep berperan di sini.
Antrian: Anda memasukkan permintaan ke dalam antrian untuk mengirimkannya dengan kecepatan yang terkendali, bukan segera. Antrian memperlancar lonjakan lalu lintas yang tiba-tiba: Bahkan jika 1.000 permintaan tiba sekaligus, antrian akan melepaskannya dengan kecepatan di bawah batas. Dengan cara ini Anda mencegah 429, maka Anda tidak perlu khawatir untuk memperbaikinya.
Batas konkurensi: Anda membatasi berapa banyak permintaan yang "mengudara" pada saat yang bersamaan. Permintaan paralel tak terbatas dengan cepat memenuhi batas RPM dan TPM. Batasan konkurensi yang masuk akal (misalnya tidak lebih dari 10 permintaan bersamaan) mempertahankan batasan dan membuat sistem dapat diprediksi.
Pemutus sirkuit: Jika penyedia terus mengembalikan 500/529, alih-alih dengan gigih mencoba setiap permintaan, Anda "memutus sirkuit" untuk sementara dan dengan cepat menggagalkan permintaan tanpa pernah mengirimkannya. Setelah menunggu, Anda hidupkan kembali sirkuit dan coba. Pola ini mencegah sistem Anda mogok jika terjadi kegagalan penyedia sementara.
Bersama-sama, ketiga hal ini membangun ketahanan tingkat sistem di luar logika percobaan ulang dalam satu panggilan. Dalam skala kecil, percobaan ulang otomatis SDK sudah cukup; Seiring bertambahnya skala, antrian, konkurensi, dan pemutus sirkuit menjadi sangat diperlukan. Mereka semua memiliki tujuan yang sama: untuk mencerminkan masalah sementara kepada pengguna bukan sebagai kerusakan, tetapi sebagai penundaan beberapa detik yang tidak terlihat.
Singkatnya
429 kembali ketika batas kecepatan (RPM/ITPM/OTPM) terlampaui; Ini adalah kesalahan sementara dan akan dicoba ulang menggunakan retry-after dan backoff eksponensial + jitter. 500 dan 529 juga bersifat sementara; 400/401/403/404 adalah masalah permintaan/identitas dan tidak dapat diselesaikan dengan mencoba lagi. Aliran yang kuat memisahkan kesalahan ke dalam dua kelompok ini, mencoba beberapa kali, memantau batas dari depan dan menampilkan pesan yang tenang kepada pengguna.
Tugas aplikasi
Pertimbangkan integrasi Anda. (1) Cantumkan kode kesalahan yang mungkin Anda temui dan pisahkan menjadi "dapat dicoba ulang/permanen". (2) Tuliskan rencana kemunduran eksponensial Anda (penahanan awal, koefisien, batas, jitter). (3) Tentukan cara menggunakan header retry-after. (4) Tulis pesan sopan untuk ditampilkan kepada pengguna ketika percobaan ulang telah habis.
daftar periksa
- [ ] Saya bisa menjelaskan batasan RPM/ITPM/OTPM dan 429.
- [ ] Saya bisa menerapkan logika mundur eksponensial + jitter + coba lagi setelahnya.
- [ ] Saya dapat mengklasifikasikan kode kesalahan sebagai dapat dicoba ulang/permanen.
- [ ] Saya tahu bahwa kita tidak seharusnya mencoba setiap kesalahan.
- [ ] Alih-alih kesalahan mentah, saya dapat menunjukkan kepada pengguna pesan yang tenang dan berorientasi pada tindakan.