Печалби:
- Може да интерпретира ограничения на скоростта (RPM/ITPM/OTPM) и 429 грешки
- Внедрява експоненциално забавяне и повторен опит с повторен опит след
- Правилно класифицира и обработва често срещани HTTP кодове за грешки (400/401/429/500/529)
В производствена среда нито един API не реагира перфектно през цялото време. Понякога изпращате заявки твърде бързо и достигате лимита; понякога сървърът е временно зает; Понякога искането ви е грешно от самото начало. Това, което отличава стабилната интеграция от аматьорския опит е, че се справя с тези ситуации предсказуемо и автоматично. В този раздел ще научите за ограниченията на скоростта (RPM/ITPM/OTPM), грешка 429, повторен опит с експоненциално забавяне и правилна класификация на често срещаните HTTP кодове за грешки. Целта: да се изгради поток, който е толкова стабилен, че потребителят никога да не го забележи.
Какво представляват ограниченията на скоростта?
Доставчикът ограничава колко работа може да свърши един комутатор за даден период от време. Тази защита; Той защитава както инфраструктурата, така и вас от внезапни експлозии на разходите. Има три често срещани вида ограничения:
- RPM (заявки в минута): Брой заявки в минута.
- ITPM (входни токени за минута): входен токен, който може да се обработва за минута.
- OTPM (Изходни токени за минута): Изходен токен, който може да бъде произведен за минута.
Ако превишите някое от тези ограничения, доставчикът отхвърля заявката и връща код за грешка 429. Лимитите обикновено варират в зависимост от нивото на вашия акаунт (ниво) и може да бъдат увеличени с времето.
Съвет: Можете да наблюдавате кога наближавате ограничението от заглавките на отговорите. Повечето доставчици отчитат оставащата ви квота със заглавки като x-ratelimit-remaining-*. Наблюдаването на тези стойности и ограничаването на трафика отпред е най-зрелият начин за предотвратяване на проблема, без да получавате 429.
429 и експоненциално корекция
429 (ограничение на скоростта) е временна грешка, която може да се опита отново. Правилният отговор е да изчакате заявката известно време и да опитате отново. Но постоянното чакане не е достатъчно; Ако всички опитат отново по едно и също време, лимитът ще бъде достигнат отново. Решението е експоненциално забавяне: експоненциално увеличаване на времето за изчакване с всеки неуспешен опит.
# Експоненциално забавяне на логически опит 1 → 429 → изчакайте 1 секунда, опит 2 → 429 → изчакайте 2 секунди, опит 3 → 429 → изчакайте 4 секунди, опит 4 → 429 → изчакайте 8 секунди (+ малък случаен "триптене")... откажете се и докладвайте след най-много N опита
Добавянето на малко случайност (трептене) към това предотвратява сблъсък на заявки, когато се опитвате да опитате отново по едно и също време. Освен това, отговорът 429 често носи заглавка „повторен опит след“: „опитайте отново след толкова много секунди“. Уважаването на това заглавие е по-точно от сляпото чакане.
Внимание: Когато получите 429, „форсирането чрез изпращане на повече заявки“ ще влоши ситуацията; Лимитът продължава да се запълва и не преминават заявки. Правилната реакция е отстъпление, а не ускорение. Добри новини: повечето официални SDK автоматично опитват отново 429 и сървърни грешки с отлагане — използвайте това поведение на SDK, преди да го инсталирате ръчно.
Класифициране на HTTP кодове за грешки
Не всяка грешка е еднаква. Критично разграничение: може ли да се опита отново или това е проблем със заявка/самоличност?
Код
Значение
Може ли да се опита отново?
правилен отговор
400
Невалидна заявка (грешка във формат/параметър)
не
Коригирайте заявката; не изпращайте същото отново
401
Грешка при удостоверяване (ключът е невалиден/липсва)
не
Коригирайте ключ/заглавие
403
Няма разрешение (няма достъп до модел/функция)
не
Проверете разрешения/обхват
404
Не е намерен (неправилен ID на модела/крайна точка)
не
Правилно ID/адрес на модела
429
Ограничението на скоростта е превишено
да
Отстъпление + повторен опит след това
500
Грешка в сървъра
да
Опитайте отново с отстъпление
529
Сървърът е претоварен
да
Опитайте отново с отстъпление
Златно правило: 429, 500 и 529 са временни; Пробва се отново с теглене. 400, 401, 403, 404 са проблеми със заявка/самоличност; Повторният опит няма да го реши и губи усилия. Вашият код трябва да прави разлика между тези две групи.
Стъпка по стъпка: Устойчиво обаждане
- Изпратете заявката. Ако е успешно, продължете.
- Класифицирайте кода на грешката. Може ли да се опита отново?
- Ако може да се опита: следвайте повторен опит след, приложете експоненциално забавяне + трептене, опитайте ограничен брой пъти (напр. 5 максимум).
- Ако не се опита: Поправете (формат/ключ) и спрете; Не повтаряйте същата грешна заявка в цикъла.
- Помислете за отказване. Ако все още не е успешен след n опита, покажете учтиво съобщение на потребителя и запишете събитието (единица за проследяване 11).
# Надеждно извикване pseudo-codedene = 0repeat: response = request_at() if response.success: върне отговор ако response.code в [429, 500, 529] и опитайте < 5: изчакайте = retry_after ?? (2^опитайте секунди + трептене) заспиване (изчакване); опитайте += 1; git отново, ако response.code в [400, 401, 403, 404]: save_error(response); return "заявката трябва да бъде коригирана" return "постоянна грешка, опитайте по-късно"
# Учтива обратна връзка към потребителя (когато повторните опити са изчерпани) „В момента съм зает, не можах да обработя заявката ви. Опитайте отново скоро или съм запазил заявката ви, ще се свържа с вас, когато е готова.“
Слаба подкана/Силна подкана (тук: дизайн на съобщение за грешка)
# СЛАБ (показва необработена грешка на потребителя) "Грешка 429: rate_limit_error"
# СИЛЕН (удобен за потребителя, успокояващ, предлагащ действие) "Имаше временно задръстване в системата. Получихме вашата заявка безопасно и се опитваме отново автоматично. Ако резултатът не се появи в рамките на няколко секунди, можете да опресните страницата."
Разкриването на грубата техническа грешка на крайния потребител едновременно подкопава доверието и може да бъде уязвимост в сигурността. Категоризирайте грешките вътрешно и дайте на потребителя спокойно, ориентирано към действие съобщение; просто напишете техническите подробности за протокола.
Три мини калъфа
Случай 1 — Лодка се разби при експлозия в трафика. Бот за обслужване на клиенти получи 429 в скок на трафика в деня на кампанията; В кода нямаше повторен опит, всяка грешка се отразяваше директно на потребителя като „грешка“. Те добавиха експоненциално корекция + повторен опит след; при същия трафик, заявките преминаха със закъснение от няколко секунди, потребителят не видя никакви грешки.
Случай 2 — Опитване на 400 в цикъла. Интеграцията получаваше 404 поради невалиден ID на модела, но третираше всички грешки като „преходни“ и опитваше отново в безкраен цикъл; Дървеният труп се изду и се създаде ненужен товар. Те добавиха класификация на грешките: 404 се счита за постоянна, цикълът се спира и идентификаторът на модела се коригира. Поука: не опитвайте всяка грешка отново.
Случай 3 — Управление на ограничението отпред. Работа за обогатяване на данни непрекъснато се изпълняваше на лимит от 429. Те последваха заглавката x-ratelimit-remain и намалиха трафика според квотата. Така те поддържаха стабилно темпо точно под лимита, без да вземат 429s; Работата беше свършена по-предсказуемо и по-бързо.
Често срещани грешки
- Увеличаване на скоростта в 429: Влошава ситуацията; Преминете към отстъпление.
- Повторен опит за всяка грешка: 400/401/404 е постоянна; Опитването отново е загуба.
- Използване на фиксирано изчакване: Създава сблъсък; Използвайте експоненциален + трептене.
- Пренебрегване на 'повтаряне след': Най-точно е да се съобразите с времето, посочено от доставчика.
- Разкриване на грубата грешка на потребителя: разклаща доверието, създава уязвимости; Класифицирайте вътре.
- Неограничени повторни опити: Задайте горна граница (напр. 5 повторни опита); след това се откажете грациозно.
По-дълбоко: опашка, паралелност и прекъсвачи
Издръжливостта на едно единствено желание е първата стъпка; Истинската зрялост е да управлявате голям брой заявки, без да достигате лимитите. Тук влизат в действие три концепции.
Опашка: Поставяте заявки в опашка, за да ги изпратите с контролирано темпо, а не веднага. Опашката изглажда внезапните изблици на трафик: Дори ако 1000 заявки пристигнат наведнъж, опашката ще ги освободи със скорост под лимита. По този начин предотвратявате 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.
- [ ] Мога да приложа логиката на експоненциално отстъпление + трептене + повторен опит след.
- [ ] Мога да класифицирам кодовете за грешки като повторни/постоянни.
- [ ] Знам, че не трябва да опитваме всяка грешка.
- [ ] Вместо необработена грешка, мога да покажа на потребителя спокойно, ориентирано към действие съобщение.