Добивки:
- Може да ги толкува ограничувањата на брзината (RPM/ITPM/OTPM) и 429 грешки
- Имплементира експоненцијално назадување и обидете се повторно со повторно обид-после
- Правилно ги класифицира и ракува со вообичаените кодови за грешки на HTTP (400/401/429/500/529)
Во производствена средина, ниту еден API не реагира совршено цело време. Понекогаш испраќате барања пребрзо и ја достигнувате границата; понекогаш серверот е привремено зафатен; Понекогаш вашето барање е погрешно од самиот почеток. Она што разликува солидна интеграција од аматерски обид е тоа што се справува со овие ситуации предвидливо и автоматски. Во оваа единица ќе научите за ограничувањата на стапката (RPM/ITPM/OTPM), грешката од 429, обидете се повторно со експоненцијално назадување и правилната класификација на вообичаените кодови за грешки на HTTP. Целта: да се изгради проток кој е толку робустен што корисникот никогаш нема да го забележи.
Кои се ограничувањата на брзината?
Давателот ограничува колку работа може да направи прекинувачот во даден временски период. Оваа заштита; Ја штити и инфраструктурата и вас од ненадејни експлозии на трошоци. Постојат три вообичаени типа на ограничувања:
- RPM (Requests per Minute): Број на барања во минута.
- ITPM (Влезни токени во минута): Влезен токен што може да се обработува во минута.
- OTPM (Излезни токени во минута): Излезен токен што може да се произведува во минута.
Ако надминете некое од овие ограничувања, давателот го одбива барањето и враќа шифра за грешка 429. Ограничувањата генерално варираат во зависност од нивото на вашата сметка (ниво) и може да се зголемуваат со текот на времето.
Совет: може да гледате кога се приближувате до лимитот од заглавијата на одговорот. Повеќето провајдери ја пријавуваат вашата преостаната квота со заглавија како x-ratelimit-remaining-*. Следењето на овие вредности и гаснењето на сообраќајот напред е најзрелиот начин да се спречи проблемот без да се добие 429.
429 и Експоненцијално повторно следење
429 (ограничување на стапката) е привремена грешка која може да се повтори. Точниот одговор е да го чекате барањето некое време и да се обидете повторно. Но, постојаното чекање не е доволно; Ако сите се обидат повторно во исто време, лимитот повторно ќе се достигне. Решението е експоненцијално назадување: зголемување на времето на чекање експоненцијално со секој неуспешен обид.
# Експоненцијална логичка проба за повлекување 1 → 429 → чекај 1 сек. проба 2 → 429 → чекај 2 сек. 3 → 429 → чекај 4 сек.
Додавањето малку случајност (дргање) на ова спречува судир на барањата кога се обидувате повторно да се обидете во исто време. Дополнително, одговорот 429 често носи заглавие „повторно-после“: „обидете се повторно за толку секунди“. Да се почитува оваа титула е попрецизно од слепо чекање.
Внимание: кога ќе добиете 429, „да го принудите со испраќање повеќе барања“ ќе ја влоши ситуацијата; Лимитот продолжува да се пополнува и никакви барања не поминуваат. Точниот одговор е повлекување, а не забрзување. Добри вести: повеќето официјални SDK автоматски се обидуваат повторно со 429 и грешки на серверот со повратен исклучок - користете го ова однесување на SDK пред да го инсталирате рачно.
Класификација на кодови за грешки на HTTP
Не секоја грешка е иста. Критична дистинкција: дали може повторно да се обиде или е прашање на барање/идентитет?
Код
Значење
Може ли да се обиде повторно?
правилен одговор
400
Неважечко барање (грешка во формат/параметар)
бр
Поправете го барањето; не го праќај повторно истото
401
Грешка при автентикација (клучот е неважечки/недостасува)
бр
Поправете го клучот/насловот
403
Нема овластување (нема пристап до модел/функција)
бр
Проверете ги дозволите/опсегот
404
Не е пронајден (неточен ID на модел/крајна точка)
бр
Точен проект/адреса на моделот
429
Ограничувањето на брзината е надминато
Да
Повлекување + повторно обид-после
500
Грешка на серверот
Да
Обидете се повторно со повлекување
529
Серверот е преоптоварен
Да
Обидете се повторно со повлекување
Златно правило: 429, 500 и 529 се привремени; Се проба повторно со повлекување. 400, 401, 403, 404 се прашања за барање/идентитет; Обидот повторно нема да го реши, и троши труд. Вашиот код мора да прави разлика помеѓу овие две групи.
Чекор по чекор: Траен повик
- Поднесете го барањето. Ако е успешна, продолжете.
- Класифицирајте го кодот за грешка. Може ли да се обиде повторно?
- Ако може да се испроба: следете го повторното обид после, применете експоненцијално назадување + нервоза, обидете се ограничен број пати (на пр. 5 максимум).
- Ако не се обиде: Поправете (форматирајте/клуч) и стопирајте; Не го повторувајте истото погрешно барање во циклусот.
- Размислете за откажување. Ако сè уште е неуспешен по n обиди, покажете му љубезна порака на корисникот и пријавете го настанот (единица за следење 11).
# Робустен повик псевдо-кодеден = 0повторување: одговор = request_at() ако answer.success: вратете одговор ако answer.code во [429, 500, 529] и обидете се < 5: чекајте = повторете_по ?? (2^пробај сек + нервоза) спиење (чекај); обидете се += 1; git повторно ако answer.code во [400, 401, 403, 404]: save_error(response); врати „барањето мора да се поправи“ врати „постојана грешка, обидете се подоцна“
# Учтиви повратни информации до корисникот (кога ќе се исцрпат повторените обиди) "Зафатен сум во моментов, не можев да го обработам вашето барање. Обидете се повторно наскоро, или го зачував вашето барање, ќе ви се вратам кога ќе биде подготвено."
Слаба порака / Силен потсетник (тука: дизајн на порака за грешка)
# СЛАБ (ја прикажува необработената грешка на корисникот) „Грешка 429: rate_limit_error“
# STRONG (пријателски за корисникот, смирувачки, сугерира акција) "Имаше привремен метеж во системот. Го добивме вашето барање безбедно и се обидува повторно автоматски. Ако резултатот не се појави во рок од неколку секунди, можете да ја освежите страницата."
Откривањето на необработената техничка грешка на крајниот корисник и ја поткопува довербата и може да биде безбедносна ранливост. Категоризирајте ги грешките внатрешно и дајте му на корисникот мирна порака ориентирана кон акција; само напишете ги техничките детали за евиденција.
Три мини футроли
Случај 1 - Брод се урна во сообраќајна експлозија. Бот за услуги на клиентите доби 429 зголемен сообраќај на денот на кампањата; Немаше повторен обид во кодот, секоја грешка се рефлектираше директно на корисникот како „грешка“. Тие додадоа експоненцијално поправка + повторно обид-по; со истиот сообраќај, барањата поминаа со задоцнување од неколку секунди, корисникот не виде никакви грешки.
Случај 2 - Обидувајќи се со 400 во јамката. Интеграцијата добиваше 404 поради неважечки ID на моделот, но ги третираше сите грешки како „минливи“ и повторно се обидуваше во бесконечна јамка; Дневникот стана отечен и се создаде непотребен товар. Тие додадоа класификација на грешки: 404 се смета за трајна, јамката е запрена и ID на моделот се коригира. Поука: не ја пробувајте секоја грешка повторно.
Случај 3 - Управување со лимитот од напред. Работата за збогатување податоци постојано работеше на лимитот 429. Тие го следеа заглавјето на преостанатиот х-рателимит и го загушија сообраќајот според квотата. Така тие одржуваа стабилно темпо веднаш под границата, без да преземат 429 секунди; Работата беше завршена попредвидливо и побрзо.
Вообичаени грешки
- Зголемување на брзината во 429: Ја влошува ситуацијата; Префрлете се на повлекување.
- Повторување на секоја грешка: 400/401/404 е постојана; Обидот повторно е губење.
- Користење на фиксно чекање: Создава судир; Користете експоненцијален + нервоза.
- Игнорирање на „повторен обид после“: Најпрецизно е да се придржувате до времето одредено од давателот.
- Откривање на суровата грешка на корисникот: ја разнишува довербата, создава ранливости; Класифицирајте внатре.
- Неограничени повторувања: поставете горна граница (на пр. 5 повторувања); тогаш грациозно откажете се.
Подлабоко: редици, истовремено и прекинувачи
Издржливоста на една единствена желба е првиот чекор; Вистинската зрелост е да управувате со голем број барања без да ги достигнете границите. Тука влегуваат во игра три концепти.
Ред: ставате барања во ред за да ги испратите со контролирано темпо наместо веднаш. Редиците ги измазнуваат ненадејните изливи на сообраќај: Дури и ако пристигнат 1.000 барања одеднаш, редот ќе ги ослободи со стапка под лимитот. На овој начин го спречувате 429, тогаш не треба да се грижите за негово поправање.
Ограничување на конкурентност: Вие ограничувате колку барања се „во воздух“ во исто време. Неограничените паралелни барања брзо ги пополнуваат ограничувањата на RPM и TPM. Разумниот плафон за истовременост (на пр. не повеќе од 10 истовремени барања) истовремено одржува ограничувања и го прави системот предвидлив.
Прекинувач: ако давателот продолжува да враќа 500/529, наместо упорно да го испробате секое барање, вие „го прекинувате колото“ некое време и брзо го пропаѓате барањето без воопшто да го испратите. По чекање, повторно го вклучувате колото и пробајте. Оваа шема го спречува паѓањето на вашиот систем во случај на привремен дефект на добавувачот.
Заедно, овие три воспоставуваат еластичност на ниво на системот надвор од логиката за повторно обид на еден повик. Во мал обем, автоматското повторување на SDK е доволно; Како што расте обемот, редот, истовременотоста и прекинувачот стануваат незаменливи. Сите тие имаат иста заедничка цел: привремениот проблем да се одрази на корисникот не како пад, туку како невидливо доцнење од неколку секунди.
Сумирано
429 се враќа кога ограничувањата на брзината (RPM/ITPM/OTPM) се надминати; Ова е привремена грешка и ќе се обиде повторно со користење на повторен обид и експоненцијално назадување + нервоза. 500 и 529 се исто така привремени; 400/401/403/404 е проблем со барање/идентитет и не може да се реши со обид повторно. Силниот тек ги раздвојува грешките во овие две групи, се обидува ограничен број пати, ја следи границата однапред и му покажува мирни пораки на корисникот.
Задача за апликација
Размислете за вашата интеграција. (1) Наведете ги шифрите за грешки што може да ги сретнете и разделете ги на „повторно пробање / трајно“. (2) Запишете го вашиот експоненцијален план за повлекување (почетно задржување, коефициент, капа, нервоза). (3) Наведете како да го користите заглавието повторно обиди после. (4) Напишете ја љубезната порака што ќе му се прикаже на корисникот кога ќе се исцрпат повторените обиди.
листа за проверка
- [ ] Можам да ги објаснам ограничувањата на RPM/ITPM/OTPM и 429.
- [ ] Можам да ја применам логиката на експоненцијално повлекување + нервоза + повторно обид-после.
- [ ] Можам да ги класифицирам шифрите за грешки како повторно пробливи/трајни.
- [ ] Знам дека не треба да се обидуваме со секоја грешка.
- [ ] Наместо сурова грешка, можам да му покажам на корисникот мирна, ориентирана кон акција порака.