Прибуток:
- Може інтерпретувати обмеження швидкості (RPM/ITPM/OTPM) і помилки 429
- Реалізує експоненціальний відкат і повторну спробу з повторною спробою після
- Правильно класифікує та обробляє типові коди помилок HTTP (400/401/429/500/529)
У робочому середовищі жоден API не завжди ідеально відповідає. Іноді ви надсилаєте запити надто швидко і досягаєте ліміту; іноді сервер тимчасово зайнятий; Іноді ваш запит неправильний із самого початку. Те, що відрізняє надійну інтеграцію від аматорської спроби, полягає в тому, що вона обробляє ці ситуації прогнозовано та автоматично. У цьому розділі ви дізнаєтесь про обмеження швидкості (RPM/ITPM/OTPM), помилку 429, повторну спробу з експоненційною відстрочкою та правильну класифікацію типових кодів помилок HTTP. Мета: побудувати потік, який буде настільки надійним, що користувач ніколи його не помітить.
Що таке обмеження швидкості?
Постачальник обмежує кількість роботи, яку комутатор може виконати за певний період часу. Цей захист; Це захищає як інфраструктуру, так і вас від раптового зростання витрат. Існує три поширених типи обмежень:
- RPM (запитів за хвилину): кількість запитів за хвилину.
- ITPM (вхідні маркери за хвилину): вхідний маркер, який можна обробити за хвилину.
- OTPM (Output Tokens Per Minute): Вихідний токен, який можна виробити за хвилину.
Якщо ви перевищите будь-яке з цих обмежень, постачальник відхилить запит і поверне код помилки 429. Обмеження зазвичай відрізняються залежно від рівня вашого облікового запису (рівня) і можуть бути збільшені з часом.
Порада: Ви можете спостерігати за наближенням до ліміту в заголовках відповідей. Більшість постачальників повідомляють про вашу квоту, що залишилася, із заголовками на зразок x-ratelimit-remaining-*. Моніторинг цих значень і придушення трафіку попереду є найбільш зрілим способом запобігти проблемі без отримання 429.
429 і експоненціальний відкат
429 (обмеження швидкості) є тимчасовою помилкою, яку можна повторити. Правильна відповідь — почекати деякий час на запит і повторити спробу. Але постійного очікування недостатньо; Якщо всі спробують ще раз одночасно, ліміт буде досягнуто знову. Рішення полягає в експоненціальному відступі: час очікування експоненціально збільшується з кожною невдалою спробою.
# Логіка експоненціального відстрочки 1 → 429 → зачекайте 1 секунда, спроба 2 → 429 → зачекайте 2 секунди, спроба 3 → 429 → зачекайте 4 секунди, спроба 4 → 429 → зачекайте 8 секунд (+ невелике випадкове "тремтіння")... здайтеся та звітуйте після не більше ніж N спроб
Додавання до цього невеликої випадковості (тремтіння) запобігає зіткненню запитів під час одночасних повторних спроб. Крім того, відповідь 429 часто містить заголовок `retry-after`: "спробуйте ще раз через стільки секунд". Поважати цей титул точніше, ніж сліпо чекати.
Застереження: коли ви отримуєте 429, «примусове надсилання додаткових запитів» погіршить ситуацію; Ліміт продовжує заповнюватися, і запити не надходять. Правильна відповідь - відступ, а не прискорення. Хороші новини: більшість офіційних SDK автоматично повторюють помилки 429 і сервер із відстрочкою — використовуйте цю поведінку SDK перед установкою вручну.
Класифікація кодів помилок HTTP
Не кожна помилка однакова. Критична відмінність: чи можна повторити спробу чи це проблема запиту/ідентифікації?
Код
Значення
Чи можна спробувати ще раз?
правильна відповідь
400
Недійсний запит (помилка формату/параметра)
немає
Виправте запит; більше не надсилайте те саме
401
Помилка автентифікації (ключ недійсний/відсутній)
немає
Виправити ключ/заголовок
403
Немає авторизації (немає доступу до моделі/функції)
немає
Перевірте дозволи/область
404
Не знайдено (неправильний ідентифікатор моделі/кінцева точка)
немає
Правильний ідентифікатор/адреса моделі
429
Перевищено обмеження швидкості
так
Відступ + повторна спроба після
500
Помилка сервера
так
Спробуйте знову з відступом
529
Сервер перевантажений
так
Спробуйте знову з відступом
Золоте правило: 429, 500 і 529 тимчасові; Повторна спроба з вилученням. 400, 401, 403, 404 – проблеми із запитом/ідентифікацією; Повторна спроба не вирішить проблему, і це марно витрачає зусилля. Ваш код повинен розрізняти ці дві групи.
Крок за кроком: надійний виклик
- Надішліть запит. У разі успіху продовжуйте.
- Класифікуйте код помилки. Чи можна спробувати ще раз?
- Якщо можна спробувати: виконайте повторну спробу після, застосуйте експоненціальне відставання + тремтіння, спробуйте обмежену кількість разів (наприклад, максимум 5).
- Якщо не спробували: виправте (формат/ключ) і зупиніть; Не повторюйте той самий помилковий запит у циклі.
- Подумайте про відмову. Якщо після n спроб усе ще не вдалося, покажіть користувачеві ввічливе повідомлення та зареєструйте подію (блок відстеження 11).
# Надійний виклик pseudo-codedene = 0repeat: response = request_at() if response.success: повернути відповідь if response.code в [429, 500, 529] і спробувати < 5: wait = 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 через недійсний ідентифікатор моделі, але розглядала всі помилки як «перехідні» та повторювала спробу в нескінченному циклі; Колода розбухла і створювалося непотрібне навантаження. Вони додали класифікацію помилок: 404 вважається постійним, цикл припиняється, а ідентифікатор моделі виправляється. Урок: не повторюйте кожну помилку знову.
Випадок 3 — Керування лімітом спереду. Завдання збагачення даних постійно виконувалося з обмеженням 429. Вони слідували заголовку x-ratelimit-remaining і регулювали трафік відповідно до квоти. Тож вони тримали стабільний темп трохи нижче межі, не беручи жодних 429-х; Робота виконувалася більш прогнозовано та швидше.
Поширені помилки
- Збільшення швидкості в 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) Укажіть, як використовувати заголовок retry-after. (4) Напишіть ввічливе повідомлення, яке буде відображатися користувачеві, коли повторні спроби вичерпано.
контрольний список
- [ ] Я можу пояснити обмеження RPM/ITPM/OTPM і 429.
- [ ] Я можу застосувати логіку експоненціального відступу + тремтіння + повторної спроби.
- [ ] Я можу класифікувати коди помилок як повторні/постійні.
- [ ] Я знаю, що ми не повинні пробувати кожну помилку.
- [ ] Замість простої помилки я можу показати користувачеві спокійне, орієнтоване на дію повідомлення.