Добици:
- Може да тумачи ограничења брзине (РПМ/ИТПМ/ОТПМ) и 429 грешака
- Имплементира експоненцијално повлачење и поновни покушај са поновним покушајем
- Исправно класификује и обрађује уобичајене ХТТП кодове грешака (400/401/429/500/529)
У производном окружењу, ниједан АПИ не реагује савршено све време. Понекад шаљете захтеве пребрзо и достижете ограничење; понекад је сервер привремено заузет; Понекад је ваш захтев погрешан од почетка. Оно што разликује чврсту интеграцију од аматерског покушаја је то што она решава ове ситуације предвидљиво и аутоматски. У овој јединици ћете научити о ограничењима брзине (РПМ/ИТПМ/ОТПМ), грешци 429, покушају поново са експоненцијалним повлачењем и правилној класификацији уобичајених ХТТП кодова грешака. Циљ: изградити ток који је толико робустан да га корисник никада неће приметити.
Шта су ограничења брзине?
Провајдер ограничава колико посла прекидач може да обави у датом временском периоду. Ова заштита; Штити и инфраструктуру и вас од изненадних експлозија трошкова. Постоје три уобичајена типа ограничења:
- РПМ (Рекуестс Пер Минуте): Број захтева у минути.
- ИТПМ (Инпут Токенс Пер Минуте): Улазни токен који се може обрадити у минути.
- ОТПМ (Оутпут Токенс Пер Минуте): Излазни токен који се може произвести у минути.
Ако прекорачите било које од ових ограничења, провајдер одбија захтев и враћа код грешке 429. Ограничења се углавном разликују у зависности од нивоа вашег налога (нивоа) и могу се временом повећати.
Савет: Можете гледати када се приближавате ограничењу из заглавља одговора. Већина провајдера пријављује вашу преосталу квоту са заглављима као што је к-рателимит-ремаининг-*. Праћење ових вредности и смањење саобраћаја испред је најзрелији начин да се спречи проблем без добијања 429.
429 и експоненцијални ретрацемент
429 (ограничење брзине) је привремена грешка која се може поновити. Тачан одговор је да сачекате захтев неко време и покушате поново. Али стално чекање није довољно; Ако сви покушају поново у исто време, граница ће поново бити достигнута. Решење је експоненцијално повлачење: експоненцијално повећање времена чекања са сваким неуспелим покушајем.
# Експоненцијална логичка проба 1 → 429 → сачекајте 1 сек пробно 2 → 429 → сачекајте 2 сек пробно 3 → 429 → сачекајте 4 сек пробно 4 → 429 → сачекајте 8 секунди (+ мали насумични „дрхтање“)... одустаните и пријавите након највише Н покушаја
Додавање мало насумичности (иттер) овоме спречава да се захтеви сударе када покушавате да покушате поново у исто време. Поред тога, одговор 429 често носи заглавље „покушај поново“: „покушај поново за оволико секунди“. Поштовање ове титуле је тачније него слепо чекање.
Опрез: Када добијете 429, „присилите га слањем више захтева“ ће погоршати ситуацију; Лимит се и даље попуњава и ниједан захтев не пролази. Тачан одговор је повлачење, а не убрзање. Добре вести: већина званичних СДК-ова аутоматски поново покушава 429 и грешке сервера уз повлачење — користите ово понашање СДК-а пре него што га ручно инсталирате.
Класификација ХТТП кодова грешака
Није свака грешка иста. Критична разлика: може ли се поново покушати или је у питању захтев/идентитет?
Код
Значење
Може ли се поново покушати?
тачан одговор
400
Неважећи захтев (грешка формата/параметра)
бр
Исправите захтев; немојте поново слати исто
401
Грешка у аутентификацији (кључ неважећи/недостаје)
бр
Поправи кључ/наслов
403
Нема овлашћења (нема приступа моделу/функцији)
бр
Проверите дозволе / опсег
404
Није пронађено (нетачан ИД модела/крајња тачка)
бр
Тачан ИД/адреса модела
429
Ограничење брзине је прекорачено
Да
Повлачење + поновни покушај после
500
Грешка сервера
Да
Покушајте поново са повлачењем
529
Сервер је преоптерећен
Да
Покушајте поново са повлачењем
Златно правило: 429, 500 и 529 су привремени; Поново се покушава са повлачењем. 400, 401, 403, 404 су питања захтева/идентитета; Поновни покушај то неће решити и троши труд. Ваш код мора разликовати ове две групе.
Корак по корак: Издржљив позив
- Поднесите захтев. Ако успе, наставите.
- Класификујте шифру грешке. Може ли се поново покушати?
- Ако је могуће: следите покушај после, примените експоненцијално повлачење + подрхтавање, покушајте ограничен број пута (нпр. максимално 5).
- Ако се не покуша: поправи (формат/тастер) и заустави; Немојте понављати исти погрешан захтев у петљи.
- Размислите о одустајању. Ако и даље не успете након н покушаја, покажите љубазну поруку кориснику и забележите догађај (јединица за праћење 11).
# Робустан позив псеудо-цодедене = 0репеат: одговор = рекуест_ат() иф респонсе.суццесс: врати одговор иф респонсе.цоде у [429, 500, 529] и покушај < 5: чекај = ретри_афтер ?? (2^покушај сек + подрхтавање) слееп(ваит); покушај += 1; гит поново иф респонсе.цоде у [400, 401, 403, 404]: саве_еррор(респонсе); ретурн "захтев мора бити поправљен" ретурн "стална грешка, покушај касније"
# Учтива повратна информација кориснику (када су поновљени покушаји исцрпљени) „Тренутно сам заузет, нисам могао да обрадим ваш захтев. Покушајте поново ускоро, или сам сачувао ваш захтев, јавићу вам се када буде спреман.“
Слабо обавештење / Јако обавештење (овде: дизајн поруке о грешци)
# ВЕАК (приказује необрађену грешку кориснику) „Грешка 429: рате_лимит_еррор“
# ЈАКО (прилагођен кориснику, умирујући, предлаже радњу) „Дошло је до привременог загушења у систему. Безбедно смо примили ваш захтев и аутоматски се поново покушава. Ако се резултат не појави у року од неколико секунди, можете освежити страницу.“
Откривање сирове техничке грешке крајњем кориснику подрива поверење и може представљати безбедносну рањивост. Интерно категоризујте грешке и дајте кориснику мирну поруку усмерену на акцију; само напишите техничке детаље за записник.
Три мини кућишта
Случај 1 — Чамац се срушио у саобраћајној експлозији. Бот за корисничку подршку добио је 429 у порасту саобраћаја на дан кампање; Није било поновног покушаја у коду, свака грешка се директно одразила на корисника као „грешка“. Додали су експоненцијално ретрацемент + ретри-афтер; са истим саобраћајем, захтеви су пролазили са закашњењем од неколико секунди, корисник није видео грешке.
Случај 2 — Покушавам 400 у петљи. Интеграција је добијала 404 због неважећег ИД модела, али је све грешке третирала као „пролазне“ и покушавала поново у бесконачној петљи; Балван је постао отечен и створено је непотребно оптерећење. Додали су класификацију грешака: 404 се сматра трајном, петља је заустављена и ИД модела је исправљен. Поука: не покушавајте поново сваку грешку.
Случај 3 — Управљање лимитом са предње стране. Посао обогаћивања података је стално радио на граници од 429. Пратили су заглавље к-рателимит-ремаининг и гасили саобраћај према квоти. Тако да су држали стабилан темпо мало испод границе, без икаквих 429; Посао је обављен предвидљивије и брже.
Уобичајене грешке
- Повећање брзине у 429: погоршава ситуацију; Пребаците се на повлачење.
- Поновни покушај сваке грешке: 400/401/404 је трајно; Покушај поново је губитак.
- Коришћење фиксног чекања: Ствара колизију; Користите експоненцијално + подрхтавање.
- Игнорисање „поновног покушаја после“: Најтачније је придржавати се времена које је одредио провајдер.
- Откривање сирове грешке кориснику: пољуља поверење, ствара рањивости; Класификујте унутра.
- Неограничени покушаји: Поставите горњу границу (нпр. 5 покушаја); онда грациозно одустани.
Дубље: ред чекања, истовременост и прекидачи
Издржљивост једне жеље је први корак; Права зрелост је да управљате великим бројем захтева без достизања граница. Овде се појављују три концепта.
Ред: Захтеве стављате у ред да бисте их послали контролисаним темпом, а не одмах. Чекање у реду изглађује изненадне навале саобраћаја: чак и ако 1.000 захтева стигне одједном, ред ће их отпустити брзином испод границе. На овај начин ћете спречити 429, а онда не морате да бринете да ли ћете га поправити.
Ограничење истовремености: Ограничавате колико захтева је „у ваздуху“ у исто време. Неограничени паралелни захтеви брзо испуњавају РПМ и ТПМ ограничења. Разумна горња граница истовремености (нпр. не више од 10 истовремених захтева) одржава ограничења и чини систем предвидљивим.
Прекидач: Ако провајдер стално враћа 500/529, уместо да упорно покушавате са сваким захтевом, на неко време „прекидате струјно коло“ и брзо не успете у захтеву, а да га никада не пошаљете. Након чекања, поново укључите коло и покушајте. Овај образац спречава да се ваш систем сруши у случају привременог квара провајдера.
Заједно, ова три успостављају отпорност на нивоу система изван логике поновног покушаја једног позива. У малом обиму, аутоматски поновни покушај СДК-а је довољан; Како обим расте, ред чекања, истовременост и прекидач постају незаменљиви. Сви имају исти заједнички циљ: да кориснику прикажу привремени проблем не као пад, већ као невидљиво кашњење од неколико секунди.
Укратко
429 се враћа када су ограничења брзине (РПМ/ИТПМ/ОТПМ) прекорачена; Ово је привремена грешка и биће поново покушана коришћењем поновног покушаја и експоненцијалног повлачења + подрхтавање. 500 и 529 су такође привремени; 400/401/403/404 је проблем са захтевом/идентитетом и не може се решити поновним покушајем. Робустан ток раздваја грешке у ове две групе, покушава ограничен број пута, прати ограничење са предње стране и показује мирне поруке кориснику.
Задатак апликације
Размотрите своју интеграцију. (1) Наведите кодове грешака на које можете да наиђете и раздвојите их на „поново покушајте/трајне“. (2) Запишите свој експоненцијални план повлачења (почетно задржавање, коефицијент, ограничење, подрхтавање). (3) Одредите како да користите заглавље за поновни покушај. (4) Напишите љубазну поруку која ће се приказати кориснику када се потроше покушаји.
контролна листа
- [ ] Могу да објасним РПМ/ИТПМ/ОТПМ ограничења и 429.
- [ ] Могу да применим логику експоненцијалног повлачења + подрхтавања + поновног покушаја.
- [ ] Могу да класификујем кодове грешака као понављајуће/трајне.
- [ ] Знам да не треба покушавати сваку грешку.
- [ ] Уместо необрађене грешке, могу да покажем кориснику мирну поруку усмерену на акцију.