Qazanclar:
- Sürət məhdudiyyətlərini (RPM/ITPM/OTPM) və 429 səhvini şərh edə bilir
- Eksponensial geri çəkilməni və təkrar cəhddən sonra təkrar cəhdi həyata keçirir
- Ümumi HTTP xəta kodlarını düzgün təsnif edir və idarə edir (400/401/429/500/529)
İstehsal mühitində heç bir API hər zaman mükəmməl cavab vermir. Bəzən sorğuları çox tez göndərirsən və limiti vurursan; bəzən server müvəqqəti məşğul olur; Bəzən xahişiniz əvvəldən səhv olur. Möhkəm inteqrasiyanı həvəskar cəhddən fərqləndirən odur ki, o, bu vəziyyətləri qabaqcadan və avtomatik idarə edir. Bu bölmədə siz dərəcə limitləri (RPM/ITPM/OTPM), 429 xətası, eksponensial geriləmə ilə təkrar cəhd və ümumi HTTP xəta kodlarının düzgün təsnifatı haqqında öyrənəcəksiniz. Məqsəd: istifadəçinin heç vaxt fərqinə varmayacağı qədər möhkəm bir axın yaratmaq.
Sürət məhdudiyyətləri nədir?
Provayder müəyyən bir müddət ərzində keçidin nə qədər iş görə biləcəyini məhdudlaşdırır. Bu müdafiə; O, həm infrastrukturu, həm də sizi qəfil xərc partlayışlarından qoruyur. Üç ümumi məhdudiyyət növü var:
- RPM (Requests Per Minute): Dəqiqədə sorğuların sayı.
- ITPM (Input Tokens Per Minute): Dəqiqədə emal oluna bilən giriş nişanı.
- OTPM (Output Tokens Per Minute): Bir dəqiqədə istehsal oluna bilən çıxış nişanı.
Bu limitlərdən hər hansı birini keçsəniz, provayder sorğunu rədd edir və 429 səhv kodunu qaytarır. Limitlər ümumiyyətlə hesab səviyyənizdən (səviyyəsindən) asılı olaraq dəyişir və zaman keçdikcə artırıla bilər.
İpucu: Siz limitə yaxınlaşdığınız zaman cavab başlıqlarından baxa bilərsiniz. Əksər provayderlər qalan kvotanızı x-ratelimit-remaining-* kimi başlıqlarla bildirir. Bu dəyərləri izləmək və öndəki trafiki azaltmaq, 429 almadan problemin qarşısını almağın ən yetkin yoludur.
429 və Eksponensial Retracement
429 (dərəcə limiti) müvəqqəti və təkrar cəhd edilə bilən xətadır. Düzgün cavab sorğunu bir müddət gözləmək və yenidən cəhd etməkdir. Lakin daimi gözləmə kifayət deyil; Hər kəs eyni vaxtda yenidən cəhd etsə, limit yenidən çatacaq. Həll yolu eksponensial geriləmədir: hər uğursuz cəhdlə gözləmə müddətini eksponent olaraq artırır.
# Eksponensial geri çəkilmə məntiqi sınağı 1 → 429 → 1 saniyə gözləyin sınaq 2 → 429 → 2 saniyə gözləyin sınaq 3 → 429 → 4 saniyə gözləyin sınaq 4 → 429 → 8 saniyə gözləyin (+ kiçik təsadüfi "citter")... imtina edin və ən çox N sınaqdan sonra hesabat verin
Buna bir az təsadüfilik (jitter) əlavə etmək eyni zamanda təkrar cəhd edərkən sorğuların toqquşmasının qarşısını alır. Bundan əlavə, 429 cavabı tez-tez "yenidən cəhddən sonra" başlığını daşıyır: "bu bir neçə saniyə ərzində yenidən cəhd edin". Bu başlığa hörmət etmək kor-koranə gözləməkdən daha doğrudur.
Diqqət: 429 aldıqda, "daha çox sorğu göndərərək onu məcbur etmək" vəziyyəti daha da pisləşdirəcək; Limit doldurulmağa davam edir və heç bir sorğu keçmir. Düzgün cavab sürətlənmə deyil, geri çəkilməkdir. Yaxşı xəbər: əksər rəsmi SDK-lar avtomatik olaraq 429-u yenidən sınayır və server xətaları geri çəkilməklə — SDK-nın bu davranışından onu əl ilə quraşdırmazdan əvvəl istifadə edin.
HTTP xəta kodlarının təsnifatı
Hər səhv eyni deyil. Kritik fərq: ona yenidən cəhd etmək olar, yoxsa bu sorğu/şəxsiyyət məsələsidir?
Kod
Mənası
Yenidən cəhd etmək olar?
düzgün cavab
400
Yanlış sorğu (format/parametr xətası)
yox
Müraciəti düzəltmək; eynisini bir daha göndərməyin
401
Doğrulama xətası (açar etibarsız/çatışmır)
yox
Açarı/başlığı düzəldin
403
İcazə yoxdur (model/xüsusiyyətə giriş yoxdur)
yox
İcazələri/əhatə dairəsini yoxlayın
404
Tapılmadı (yanlış model ID/son nöqtə)
yox
Düzgün model ID/ünvanı
429
Sürət həddi keçdi
Bəli
Geri çəkilmək + sonra yenidən cəhd edin
500
Server xətası
Bəli
Geri çəkilməklə yenidən cəhd edin
529
Server həddən artıq yüklənib
Bəli
Geri çəkilməklə yenidən cəhd edin
Qızıl qayda: 429, 500 və 529 müvəqqətidir; Geri çəkilməklə yenidən sınaqdan keçirilir. 400, 401, 403, 404 sorğu/şəxsiyyət məsələləridir; Yenidən cəhd problemi həll etməyəcək və zəhmət sərf edir. Kodunuz bu iki qrup arasında fərq qoymalıdır.
Addım-addım: Davamlı Zəng
- Müraciəti təqdim edin. Uğurlu olarsa, davam edin.
- Səhv kodunu təsnif edin. Yenidən cəhd etmək olar?
- Sınaya bilərsinizsə: təkrar cəhddən sonra izləyin, eksponensial geri çəkilmə + titrəmə tətbiq edin, məhdud sayda cəhd edin (məsələn, maks. 5).
- Əgər cəhd etməsəniz: Düzəlt (format/açar) və dayandırın; Döngədə eyni səhv sorğunu təkrarlamayın.
- Təslim olmağı düşünün. Əgər n cəhddən sonra hələ də uğursuz olarsa, istifadəçiyə nəzakətli mesaj göstərin və hadisəni qeyd edin (izləmə vahidi 11).
# Möhkəm zəng pseudo-codedene = 0repeat: cavab = request_at() əgər cavab.success: əgər cavab.code [429, 500, 529]-da cavabı qaytarın və < 5 cəhd edin: gözləyin = yenidən cəhd edin ?? (2^ cəhd saniyə + titrəmə) yuxu (gözləyin); cəhd edin += 1; git yenidən əgər cavab.kod [400, 401, 403, 404]-də: save_error(cavab); "sorğu düzəldilməlidir" qaytarın "daimi xəta, sonra cəhd edin"
# İstifadəçi ilə nəzakətli rəy (yenidən cəhdlər tükəndikdə) "Hazırda məşğulam, sorğunuzu icra edə bilmədim. Tezliklə yenidən cəhd edin, yoxsa sorğunuzu yadda saxladım, hazır olanda sizinlə əlaqə saxlayacağam."
Zəif məlumat / Güclü göstəriş (burada: səhv mesajı dizaynı)
# WEAK (istifadəçiyə xam səhv göstərir)"Xəta 429: rate_limit_error"
# GÜÇLÜ (istifadəçi üçün əlverişli, arxayınlaşdırıcı, fəaliyyət təklif edən) "Sistemdə müvəqqəti sıxlıq yarandı. Sorğunuzu təhlükəsiz şəkildə aldıq və o, avtomatik olaraq yenidən sınaqdan keçirilir. Nəticə bir neçə saniyə ərzində görünməzsə, səhifəni yeniləyə bilərsiniz."
Xam texniki xətanın son istifadəçiyə açıqlanması həm etibarı sarsıdır, həm də təhlükəsizlik zəifliyi ola bilər. Səhvləri daxili kateqoriyalara ayırın və istifadəçiyə sakit, hərəkətə yönəlmiş mesaj verin; sadəcə qeyd üçün texniki detalları yazın.
Üç mini qutu
1-ci hal - Qayıq yol qəzasında qəzaya uğradı. Müştəri xidməti botu kampaniya günündə 429 artım əldə etdi; Kodda təkrar cəhd yox idi, hər bir səhv birbaşa istifadəçiyə “xəta” kimi əks olundu. Onlar eksponensial geri çəkilmə + təkrar cəhd əlavə etdi; eyni trafiklə sorğular bir neçə saniyə gecikmə ilə keçdi, istifadəçi heç bir səhv görmədi.
Case 2 - Döngüdə 400 cəhdi. İnteqrasiya etibarsız model identifikatoruna görə 404 əldə etdi, lakin bütün səhvləri "keçici" kimi qiymətləndirdi və sonsuz dövrədə yenidən cəhd etdi; Günlük şişdi və lazımsız yük yarandı. Onlar səhv təsnifatını əlavə etdilər: 404 daimi hesab olunur, dövrə dayandırılır və model ID-si düzəldilir. Dərs: hər səhvi təkrar etməyə çalışmayın.
3-cü vəziyyət - Həddini ön tərəfdən idarə etmək. Məlumat zənginləşdirmə işi daim 429 limitində işləyirdi. Onlar x-ratelimit-qalan başlığı izlədilər və kvotaya uyğun olaraq trafiki dayandırdılar. Beləliklə, onlar heç bir 429 saniyə çəkmədən sabit tempi limitdən bir qədər aşağı saxladılar; İş daha proqnozlaşdırıla bilən və daha sürətli edildi.
Ümumi səhvlər
- 429-da sürətin artırılması: Vəziyyəti daha da pisləşdirir; Geri çəkilməyə keçin.
- Hər bir xətanın yenidən sınanması: 400/401/404 daimidir; Yenidən cəhd etmək israfçılıqdır.
- Sabit gözləmədən istifadə: Toqquşma yaradır; Eksponensial + titrəmə istifadə edin.
- "Sonra təkrar cəhd"ə məhəl qoymamaq: Provayder tərəfindən göstərilən vaxta riayət etmək ən doğrudur.
- Xam səhvin istifadəçiyə üzə çıxarılması: Etibarı sarsıdır, zəifliklər yaradır; İçəridə təsnif edin.
- Limitsiz təkrar cəhdlər: Üst limit təyin edin (məsələn, 5 cəhd); sonra nəzakətlə imtina edin.
Daha dərin: Queuing, Concurrency və Circuit Breakers
Tək istəyin dözümü ilk addımdır; Həqiqi yetkinlik, həddən artıq çox sayda sorğunu idarə etməkdir. Burada üç anlayış meydana çıxır.
Növbə: Sorğuları dərhal deyil, idarə olunan sürətlə göndərmək üçün növbəyə qoyursunuz. Növbə qəfil tıxacları aradan qaldırır: Bir anda 1000 sorğu gəlsə belə, növbə onları limitdən aşağı sürətlə buraxacaq. Bu yolla siz 429-un qarşısını almış olursunuz, sonra onu düzəltməkdən narahat olmayacaqsınız.
Paralellik limiti: Siz eyni anda neçə sorğunun "havada" olmasını məhdudlaşdırırsınız. Limitsiz paralel sorğular RPM və TPM limitlərini tez doldurur. Ağlabatan paralellik tavanı (məsələn, eyni vaxtda 10-dan çox olmayan sorğu) həm limitləri qoruyur, həm də sistemi proqnozlaşdırıla bilən edir.
Devre açarı: Əgər provayder 500/529 qaytarmağa davam edərsə, hər sorğuya inadla cəhd etmək əvəzinə, siz bir müddət "dövrəni pozursunuz" və sorğunu heç göndərmədən tez bir zamanda uğursuzluqla qarşılayırsınız. Bir müddət gözlədikdən sonra dövrəni yenidən yandırın və cəhd edin. Bu nümunə provayderin müvəqqəti nasazlığı halında sisteminizin qəzaya uğramasının qarşısını alır.
Birlikdə, bu üçü tək çağırışın təkrar cəhd məntiqindən kənar sistem səviyyəsində dayanıqlıq yaradır. Kiçik miqyasda, SDK-nın avtomatik təkrar cəhdi kifayətdir; Ölçək böyüdükcə növbə, paralellik və elektrik açarı əvəzolunmaz olur. Onların hamısının ümumi məqsədi eynidir: müvəqqəti problemi istifadəçiyə qəza kimi deyil, bir neçə saniyəlik görünməz gecikmə kimi əks etdirmək.
Xülasə
429 sürət həddi (RPM/ITPM/OTPM) keçdikdə qayıdır; Bu müvəqqəti xətadır və təkrar cəhddən sonra və eksponensial geriləmə + titrəyişdən istifadə edərək yenidən cəhd ediləcək. 500 və 529 da müvəqqətidir; 400/401/403/404 sorğu/identifikasiya problemidir və yenidən cəhd etməklə həll edilə bilməz. Güclü bir axın səhvləri bu iki qrupa ayırır, məhdud sayda cəhd edir, limiti ön tərəfdən izləyir və istifadəçiyə sakit mesajlar göstərir.
Tətbiq tapşırığı
İnteqrasiyanızı düşünün. (1) Qarşılaşa biləcəyiniz xəta kodlarını sadalayın və onları "yenidən cəhd edilə bilən / qalıcı" olaraq ayırın. (2) Eksponensial geri çəkilmə planınızı yazın (ilkin saxlama, əmsal, qapaq, titrəmə). (3) Yenidən cəhddən sonra başlığın necə istifadə olunacağını göstərin. (4) Yenidən cəhdlər bitdikdə istifadəçiyə göstəriləcək nəzakətli mesajı yazın.
yoxlama siyahısı
- [ ] RPM/ITPM/OTPM limitlərini və 429-u izah edə bilərəm.
- [ ] Mən eksponensial geri çəkilmə + titrəmə + təkrar cəhd məntiqini tətbiq edə bilərəm.
- [ ] Mən xəta kodlarını təkrar sınana bilən/daimi olaraq təsnif edə bilərəm.
- [ ] Bilirəm ki, hər səhvi sınamamalıyıq.
- [ ] Xam səhv əvəzinə istifadəçiyə sakit, fəaliyyət yönümlü mesaj göstərə bilərəm.