Zyski:
- Potrafi interpretować ograniczenia prędkości (RPM/ITPM/OTPM) i błędy 429
- Implementuje wykładnicze wycofywanie i ponawianie prób z ponowieniem
- Prawidłowo klasyfikuje i obsługuje typowe kody błędów HTTP (400/401/429/500/529)
W środowisku produkcyjnym żaden interfejs API nie reaguje idealnie przez cały czas. Czasami wysyłasz żądania zbyt szybko i osiągasz limit; czasami serwer jest chwilowo zajęty; Czasami Twoja prośba jest od początku błędna. Tym, co odróżnia solidną integrację od próby amatorskiej, jest to, że radzi sobie z takimi sytuacjami predykcyjnie i automatycznie. W tym module dowiesz się o limitach prędkości (RPM/ITPM/OTPM), błędzie 429, ponawianiu prób z wykładniczym cofaniem i właściwej klasyfikacji typowych kodów błędów HTTP. Cel: zbudować przepływ tak solidny, że użytkownik go nigdy nie zauważy.
Jakie są ograniczenia prędkości?
Dostawca ogranicza ilość pracy, jaką przełącznik może wykonać w danym okresie czasu. Ta ochrona; Chroni zarówno infrastrukturę, jak i Ciebie przed nagłymi eksplozjami kosztów. Istnieją trzy popularne typy limitów:
- RPM (żądania na minutę): liczba żądań na minutę.
- ITPM (tokeny wejściowe na minutę): token wejściowy, który można przetworzyć na minutę.
- OTPM (tokeny wyjściowe na minutę): token wyjściowy, który można wyprodukować na minutę.
Jeśli przekroczysz którykolwiek z tych limitów, dostawca odrzuci żądanie i zwróci kod błędu 429. Limity zazwyczaj różnią się w zależności od poziomu konta (poziomu) i mogą z czasem zostać zwiększone.
Wskazówka: możesz zobaczyć, kiedy zbliżasz się do limitu, przeglądając nagłówki odpowiedzi. Większość dostawców zgłasza pozostały limit za pomocą nagłówków takich jak x-ratelimit-remaining-*. Monitorowanie tych wartości i ograniczanie ruchu z przodu to najbardziej dojrzały sposób zapobiegania problemowi bez uzyskiwania błędu 429.
429 i zniesienie wykładnicze
429 (limit szybkości) to błąd tymczasowy, który można powtórzyć. Prawidłową reakcją jest chwilę poczekać na żądanie i spróbować ponownie. Ale ciągłe czekanie nie wystarczy; Jeśli wszyscy spróbują ponownie w tym samym czasie, limit zostanie ponownie osiągnięty. Rozwiązaniem jest wykładnicze wycofywanie: wykładnicze wydłużanie czasu oczekiwania przy każdej nieudanej próbie.
# Wykładnicza logika wycofywania próba 1 → 429 → poczekaj 1 sek. próba 2 → 429 → poczekaj 2 sek. próba 3 → 429 → poczekaj 4 sek. próba 4 → 429 → poczekaj 8 sek. (+ małe losowe „jitter”)... poddaj się i zgłoś po co najwyżej N próbach
Dodanie do tego odrobiny losowości (jitter) zapobiega kolizjom żądań podczas jednoczesnej próby ponawiania. Dodatkowo odpowiedź 429 często zawiera nagłówek „retry-after”: „spróbuj ponownie za tyle sekund”. Szanowanie tego tytułu jest dokładniejsze niż ślepe czekanie.
Uwaga: gdy otrzymasz błąd 429, „wymuszenie go poprzez wysłanie większej liczby żądań” pogorszy sytuację; Limit jest nadal zapełniany i żadne żądania nie są realizowane. Prawidłową reakcją jest wycofanie się, a nie przyspieszenie. Dobra wiadomość: większość oficjalnych zestawów SDK automatycznie ponawia próbę 429 i błędów serwera z wycofywaniem — użyj tego zachowania zestawu SDK przed jego ręczną instalacją.
Klasyfikacja kodów błędów HTTP
Nie każdy błąd jest taki sam. Krytyczne rozróżnienie: czy można spróbować ponownie, czy jest to kwestia żądania/tożsamości?
Kod
Znaczenie
Czy można spróbować jeszcze raz?
poprawna odpowiedź
400
Nieprawidłowe żądanie (błąd formatu/parametru)
nie
Popraw żądanie; nie wysyłaj tego samego ponownie
401
Błąd uwierzytelnienia (klucz nieprawidłowy/brakujący)
nie
Napraw klucz/tytuł
403
Brak autoryzacji (brak dostępu do modelu/funkcji)
nie
Sprawdź uprawnienia/zakres
404
Nie znaleziono (nieprawidłowy identyfikator modelu/punkt końcowy)
nie
Prawidłowy identyfikator/adres modelu
429
Przekroczono dozwoloną prędkość
Tak
Wycofaj się + ponów próbę
500
Błąd serwera
Tak
Spróbuj ponownie z wycofaniem
529
Serwer przeciążony
Tak
Spróbuj ponownie z wycofaniem
Złota zasada: 429, 500 i 529 są tymczasowe; Próbuje się ponownie z wycofaniem. 400, 401, 403, 404 to problemy z żądaniami/tożsamością; Ponowna próba nie rozwiąże problemu i marnuje wysiłek. Twój kod musi rozróżniać te dwie grupy.
Krok po kroku: trwałe połączenie
- Prześlij żądanie. Jeśli się powiedzie, kontynuuj.
- Sklasyfikuj kod błędu. Czy można spróbować jeszcze raz?
- Jeśli można to wypróbować: wykonaj ponowną próbę, zastosuj wykładnicze wycofywanie + jitter, spróbuj ograniczoną liczbę razy (np. maksymalnie 5).
- Jeśli nie próbowałeś: Napraw (format/klucz) i zatrzymaj; Nie powtarzaj tego samego błędnego żądania w pętli.
- Rozważ rezygnację. Jeśli po n próbach nadal się to nie udaje, wyświetl użytkownikowi uprzejmą wiadomość i zarejestruj zdarzenie (jednostka śledząca 11).
# Solidne wywołanie pseudo-codedene = 0repeat: odpowiedź = request_at() if odpowiedź.success: zwróć odpowiedź, jeśli kod odpowiedzi w [429, 500, 529] i spróbuj < 5: Wait = retry_after ?? (2^spróbuj sek. + drżenie) usypiaj (czekaj); spróbuj += 1; git ponownie, jeśli kod odpowiedzi w [400, 401, 403, 404]: save_error (odpowiedź); return „żądanie musi zostać naprawione” return „trwały błąd, spróbuj później”
# Uprzejma informacja zwrotna dla użytkownika (po wyczerpaniu się liczby prób) „Jestem teraz zajęty, nie mogłem przetworzyć Twojej prośby. Spróbuj ponownie wkrótce lub zapisałem Twoją prośbę. Skontaktuję się z Tobą, gdy będzie gotowa”.
Słaby monit / Silny monit (tutaj: projekt komunikatu o błędzie)
# SŁABY (wyświetla użytkownikowi nieprzetworzony błąd) „Błąd 429: error_limit_error”
# STRONG (przyjazny dla użytkownika, uspokajający, sugerujący działanie) „W systemie wystąpiło tymczasowe przeciążenie. Bezpiecznie otrzymaliśmy Twoje żądanie i jest ono automatycznie testowane ponownie. Jeśli wynik nie pojawi się w ciągu kilku sekund, możesz odświeżyć stronę.”
Ujawnienie użytkownikowi końcowemu pierwotnego błędu technicznego podważa zaufanie i może stanowić lukę w zabezpieczeniach. Kategoryzuj błędy wewnętrznie i przekaż użytkownikowi spokojny, zorientowany na działanie komunikat; po prostu napisz szczegóły techniczne płyty.
Trzy mini etui
Przypadek 1 — Łódź rozbiła się w wyniku eksplozji drogowej. W dniu kampanii bot obsługi klienta odnotował wzrost ruchu o wartości 429; W kodzie nie było ponownej próby, każdy błąd był odzwierciedlany bezpośrednio przez użytkownika jako „błąd”. Dodali zniesienie wykładnicze + ponowną próbę; przy tym samym ruchu żądania przekazywane były z kilkusekundowym opóźnieniem, użytkownik nie zauważył żadnych błędów.
Przypadek 2 — Próba 400 w pętli. Integracja otrzymywała błąd 404 z powodu nieprawidłowego identyfikatora modelu, ale traktowała wszystkie błędy jako „przejściowe” i próbowała ponownie w nieskończonej pętli; Kłoda spuchła i powstało niepotrzebne obciążenie. Dodali klasyfikację błędów: 404 uważa się za trwały, pętla zostaje zatrzymana, a identyfikator modelu zostaje poprawiony. Lekcja: nie próbuj ponownie każdego błędu.
Przypadek 3 — Zarządzanie limitem od przodu. Zadanie wzbogacania danych było stale uruchomione na limicie 429. Podążali za nagłówkiem x-ratelimit-remaining i ograniczali ruch zgodnie z limitem. Utrzymywali więc stałe tempo tuż poniżej limitu, nie pokonując żadnych 429; Praca została wykonana bardziej przewidywalnie i szybciej.
Typowe błędy
- Zwiększanie prędkości w 429: Pogarsza sytuację; Przełącz na odwrót.
- Ponowna próba każdego błędu: 400/401/404 jest trwała; Ponowna próba to strata czasu.
- Korzystanie ze stałego oczekiwania: Tworzy kolizję; Użyj wykładniczego + jittera.
- Ignorowanie „ponownej próby”: najdokładniejsze jest przestrzeganie czasu określonego przez dostawcę.
- Ujawnienie użytkownikowi pierwotnego błędu: podważa zaufanie, tworzy luki w zabezpieczeniach; Klasyfikuj wewnątrz.
- Nieograniczona liczba ponownych prób: ustaw górny limit (np. 5 ponownych prób); to poddaj się z godnością.
Deeper: Kolejkowanie, współbieżność i wyłączniki automatyczne
Wytrwałość pojedynczego pragnienia jest pierwszym krokiem; Prawdziwa dojrzałość polega na zarządzaniu dużą liczbą żądań bez przekraczania limitów. W grę wchodzą tu trzy koncepcje.
Kolejka: umieszczasz żądania w kolejce, aby wysyłać je w kontrolowanym tempie, a nie natychmiast. Kolejkowanie łagodzi nagłe wzrosty ruchu: nawet jeśli 1000 żądań wpłynie jednocześnie, kolejka zwolni je z szybkością poniżej limitu. W ten sposób zapobiegniesz 429 i nie będziesz musiał się martwić o jego naprawienie.
Limit współbieżności: ograniczasz liczbę żądań jednocześnie „w powietrzu”. Nieograniczone równoległe żądania szybko wypełniają limity RPM i TPM. Rozsądny pułap współbieżności (np. nie więcej niż 10 jednoczesnych żądań) zarówno utrzymuje ograniczenia, jak i sprawia, że system jest przewidywalny.
Przerywacz obwodu: Jeśli dostawca ciągle zwraca 500/529, zamiast uparcie próbować każdego żądania, na chwilę „przerwasz obwód” i szybko odrzucasz żądanie, nigdy go nie wysyłając. Po odczekaniu włączasz obwód ponownie i próbujesz. Ten wzorzec zapobiega awarii systemu w przypadku tymczasowej awarii dostawcy.
Razem te trzy elementy zapewniają odporność na poziomie systemu wykraczającą poza logikę ponawiania pojedynczego wywołania. Na małą skalę wystarczy automatyczna ponowna próba pakietu SDK; W miarę wzrostu skali kolejkowanie, współbieżność i wyłącznik automatyczny stają się niezbędne. Wszystkie mają ten sam wspólny cel: pokazać użytkownikowi tymczasowy problem nie jako awarię, ale jako niewidoczne kilkusekundowe opóźnienie.
Podsumowując
429 powraca w przypadku przekroczenia ograniczeń prędkości (RPM/ITPM/OTPM); Jest to błąd tymczasowy i zostanie ponowiony przy użyciu ponownej próby i wykładniczego wycofywania + fluktuacji. 500 i 529 są również tymczasowe; 400/401/403/404 jest problemem związanym z żądaniem/tożsamością i nie można go rozwiązać, próbując ponownie. Solidny przepływ dzieli błędy na te dwie grupy, próbuje ograniczoną liczbę razy, monitoruje limit od przodu i wyświetla użytkownikowi spokojne komunikaty.
Zadanie aplikacji
Rozważ swoją integrację. (1) Wypisz kody błędów, które możesz napotkać i podziel je na „możliwe do ponowienia/stałe”. (2) Zapisz swój wykładniczy plan wycofania (początkowe utrzymanie, współczynnik, ograniczenie, jitter). (3) Określ, jak używać nagłówka ponownej próby. (4) Napisz komunikat grzecznościowy, który będzie wyświetlany użytkownikowi po wyczerpaniu się liczby ponownych prób.
lista kontrolna
- [ ] Mogę wyjaśnić limity RPM/ITPM/OTPM i 429.
- [ ] Potrafię zastosować logikę wykładniczego wycofania + drgań + ponownych prób.
- [ ] Mogę sklasyfikować kody błędów jako powtarzalne/stałe.
- [ ] Wiem, że nie należy próbować każdego błędu.
- [ ] Zamiast surowego błędu mogę pokazać użytkownikowi spokojny komunikat nastawiony na działanie.