ГоловнаБлогМасштабованість Tracking API: як працювати з обсягами в піковий сезон, обмеженнями частоти запитів і масовою реєстрацією

Масштабованість Tracking API: як працювати з обсягами в піковий сезон, обмеженнями частоти запитів і масовою реєстрацією

17TRACK

Щоб масштабувати API відстеження в піковий сезон, розмістіть реєстрацію відправлень за надійною чергою, застосовуйте обмеження провайдера для всіх робочих процесів, виконуйте пакетну обробку лише в межах задокументованих обмежень, а оновлення відстеження обробляйте асинхронно. Розглядайте пропускну здатність реєстрації, трафік повторних спроб і обробку вебхуків як окремі проблеми місткості. Додавання нових робочих процесів без контролю вихідних запитів може посилити обмеження швидкості замість очищення черги.

Масштабованість API відстеження: як обробляти обсяг у піковий сезон

Для інженерних команд, які підключають систему керування замовленнями, складську платформу або бекенд електронної комерції до сервісу відстеження, мета полягає не просто в надсиланні більшої кількості запитів. Потрібно зареєструвати відправлення у визначений проміжок часу, зберегти оновлення під час стрибків трафіку та відновитися після збоїв без створення дубльованої роботи.

Оцінюйте навантаження за відправленнями, запитами та оновленнями

Щоденного обсягу відправлень недостатньо для визначення розміру інтеграції. Склад може випускати більшість номерів відстеження протягом короткого періоду відправлення, тоді як оновлення статусів надходять упродовж усього дня. Моделюйте ці навантаження окремо.

  • Надходження реєстрацій: кількість нових записів про відправлення, що надходять у вашу систему за секунду або хвилину, включно з імпортами та сплесками під час випуску зі складу.
  • Вихідний трафік API: запити на реєстрацію, пошук, виправлення, звірку та повторні спроби.
  • Вхідний трафік оновлень: доставки вебхуків і повторні доставки, якщо провайдер їх підтримує.
  • Подальша обробка: записи до бази даних, сповіщення клієнтів, аналітичні події та зміни статусу замовлення, спричинені кожним оновленням.

Визначте внутрішню ціль реєстрації, наприклад максимально прийнятний час між отриманням номера відстеження та підтвердженням його реєстрації. Не змішуйте її зі свіжістю даних відстеження: успішна реєстрація не означає, що сканування перевізником уже доступне.

Розрахунок фактичної пропускної здатності реєстрації

Для кінцевої точки реєстрації з обмеженням кількості запитів корисним співвідношенням для планування є:

Пропускна здатність реєстрації = дозволена кількість запитів за секунду × середня кількість записів у запиті × частка успішних записів

Це оцінка для планування, а не гарантія провайдера. Вона передбачає, що обмеження кількості запитів є визначальним. Квоти на основі записів, розмір корисного навантаження, затримка та спільні обмеження облікового запису можуть встановлювати нижчу верхню межу.

Лише для ілюстрації припустімо, що інтеграції дозволено виконувати два запити на реєстрацію за секунду, а середній пакет містить 30 записів. Її номінальна пропускна здатність до врахування збоїв та інших обмежень становить 60 записів за секунду. Якщо під час тривалого сплеску вхідні реєстрації надходять із середньою швидкістю 80 записів за секунду, черга зростає приблизно на 20 записів за секунду. Ці цифри є гіпотетичними, а не обмеженнями 17TRACK.

Також розрахуйте пропускну здатність відновлення. Якщо нові надходження тривають зі швидкістю λ, а фактична пропускна здатність обробки становить μ, наявна черга з B записів очищується приблизно за B / (μ − λ) секунд, якщо μ > λ. Якщо пропускна здатність обробки не перевищує швидкість надходження, за таких умов черга не очиститься.

Підтвердьте, що саме обмежує провайдер

Обмеження швидкості та ліміт використання вирішують різні проблеми. Обмеження швидкості контролює, наскільки швидко можна надсилати запити або записи. Ліміт використання може визначати, який обсяг операцій відстеження обліковий запис може спожити протягом розрахункового або передбаченого умовами періоду. Дотримання одного обмеження не означає дотримання іншого.

Перш ніж визначати кількість робочих процесів, перевірте за документацією провайдера та умовами вашого облікового запису:

  • Чи застосовуються обмеження до облікового запису, ключа API, кінцевої точки, IP-адреси або іншого рівня.
  • Яка одиниця враховується: запит, запис відстеження або інша операція.
  • Чи мають кінцеві точки спільне обмеження або незалежні ліміти.
  • Максимальну кількість записів і розмір корисного навантаження, дозволені в одному запиті.
  • Як дубльовані надсилання, недійсні записи та повторні спроби впливають на використання.
  • Чи містять відповіді інформацію про обмеження швидкості або рекомендації щодо повторної спроби.
  • Чим вичерпання квоти відрізняється від тимчасового обмеження швидкості.

Для інтеграції з 17TRACK використовуйте офіційну сторінку Tracking API та документацію API як початкові джерела для цього налаштування. Перед розгортанням підтвердьте поведінку відповідної кінцевої точки та обмеження облікового запису. Приклади пропускної здатності в цьому посібнику ілюструють архітектуру, а не є твердженнями щодо доступних 17TRACK лімітів, розмірів пакетів або гарантій сервісу.

Розмістіть надійну чергу між обробкою замовлень і реєстрацією

Не змушуйте оформлення замовлення або завершення складської операції чекати, поки провайдер відстеження прийме реєстрацію. Збережіть відправлення локально, надійно запишіть завдання реєстрації та доручіть його надсилання фоновим робочим процесам.

Практичний процес:

  1. Збережіть відправлення та намір його зареєструвати. Використовуйте транзакційний outbox або еквівалентну схему, щоб не зберегти замовлення, втративши фонове завдання.
  2. Перевірте та нормалізуйте вхідні дані. Зберігайте номери відстеження як рядки, включно з початковими нулями. Застосовуйте специфічну для перевізника нормалізацію лише за наявності обґрунтування.
  3. Перевірте наявність уже виконаної реєстрації. Використовуйте стабільний ідентифікатор, що відповідає провайдеру та вашій моделі даних.
  4. Помістіть придатні записи в чергу. Зберігайте кількість спроб, час наступної дозволеної повторної спроби та достатній контекст для діагностики.
  5. Надсилайте через спільний обмежувач. Отримуйте доступ до пропускної здатності безпосередньо перед вихідним запитом.
  6. Зберігайте результати на рівні записів. Розділяйте підтверджений успіх, помилку, яку можна повторити, постійну відмову та неоднозначні результати.

Черга поглинає сплеск, але не створює пропускної здатності провайдера. Якщо найстаріший придатний запис постійно старіє, досліджуйте розрив між швидкістю надходження та пропускною здатністю обробки, а не просто збільшуйте кількість робочих процесів.

Координуйте обмеження між робочими процесами

Незалежні робочі процеси не повинні вважати, що кожен із них може використати повний ліміт облікового запису. Використовуйте скоординований обмежувач швидкості або диспетчер, який розподіляє спільний бюджет запитів. Включайте до цього бюджету заплановані імпорти, операційні скрипти та завдання звірки.

Швидкість і паралельність — різні засоби контролю. Обмежувач контролює, як часто запускаються запити, а обмеження паралельності — скільки запитів одночасно перебувають у виконанні. Обидва засоби корисні, коли затримка провайдера зростає. Збільшення паралельності може допомогти навантаженню, обмеженому затримкою, але не може обійти обмеження вихідної швидкості.

Використовуйте пакетну реєстрацію, не втрачаючи контролю на рівні записів

Якщо кінцева точка підтримує кілька записів в одному запиті, пакетна обробка може зменшити накладні витрати на запити. Вона не обов’язково зменшує використання, що обліковується за записами, а найбільший дозволений пакет не завжди є найкращим операційним вибором.

Формуйте пакети за двома тригерами: максимальною кількістю записів і максимальним часом очікування. Надсилайте пакет, коли спрацьовує будь-який із них. Це дає змогу ефективно заповнювати пакети в завантажені періоди, не змушуючи трафік із низьким обсягом чекати невизначено довго.

  • Дотримуйтеся обмежень корисного навантаження, а не лише кількості записів. Необов’язкові метадані можуть зробити пакети однакового розміру дуже різними за кількістю байтів.
  • Зберігайте внутрішній маніфест пакета. Записуйте, які локальні ідентифікатори відправлень були надіслані, і правильно пов’язуйте кожен отриманий результат.
  • Перевіряйте результати на рівні застосунку. Успішна відповідь HTTP сама по собі не доводить, що кожен запис було прийнято.
  • Повторюйте лише ті записи, для яких це потрібно. Повторне надсилання успішних записів створює зайвий трафік і може вплинути на використання.
  • Спрямовуйте постійні помилки перевірки на виправлення. Незмінне недійсне корисне навантаження не повинно циркулювати через чергу повторних спроб.

Особливо важливим є тайм-аут: провайдер міг прийняти запит, навіть якщо ваш клієнт не отримав відповіді. Позначайте такий результат як неоднозначний. Вирішуйте ситуацію за допомогою підтримуваного механізму ідемпотентності, задокументованого правила повторної реєстрації або доступного запиту звірки. Не припускайте, що запис, для якого минув тайм-аут, не було виконано.

Відокремлюйте поточний трафік від історичних імпортів

Зворотне заповнення не повинно використовувати всю пропускну здатність, необхідну для щойно відправлених відправлень. Використовуйте окремі черги зі зваженим плануванням або явним резервуванням пропускної здатності. Дозвольте імпортам використовувати вільну пропускну здатність, зберігаючи мінімальну частку для поточних реєстрацій. Застосовуйте старіння або інше правило справедливості, щоб записи нижчого пріоритету зрештою оброблялися.

Контролюйте, відкладіть і обмежте повторні спроби

HTTP 429 означає «Забагато запитів». RFC 6585 визначає, що відповідь 429 може містити заголовок Retry-After. RFC 9110 визначає значення цього заголовка як дату HTTP або затримку в секундах. Клієнт має обробляти обидві форми, а не припускати, що завжди повертається ціле число.

Якщо вказано дійсну затримку повторної спроби, не повторюйте запит до її завершення. Якщо рекомендації щодо повторної спроби відсутні, використовуйте експоненційну затримку з обмеженням і випадковою складовою: поступово збільшуйте інтервал між спробами та додавайте випадковість, щоб усі робочі процеси не повторювали запити одночасно. Повторні спроби мають проходити через той самий обмежувач вихідного трафіку, що й перші спроби.

Класифікуйте помилки перед повторною спробою:

  • Обмеження швидкості: відкладіть відповідну роботу та зменште навантаження на диспетчеризацію в межах відповідного рівня обмеження.
  • Тимчасові мережеві або серверні збої: повторюйте спроби в межах обмеженої політики, враховуючи неоднозначні результати запису.
  • Помилки автентифікації або авторизації: надішліть сповіщення та призупиніть відповідну роботу, доки облікові дані або дозволи не буде виправлено.
  • Помилки перевірки: виправте або ізолюйте запис, а не надсилайте його без змін.
  • Вичерпаний ліміт: дотримуйтеся задокументованого способу вирішення проблеми з обліковим записом, а не сприймайте її як короткочасний сплеск трафіку.

Встановіть обмеження кількості спроб і максимальний вік повторних спроб. Переміщуйте вичерпані елементи до черги недоставлених повідомлень із зазначенням причини, відповідального та процедури повторного відтворення. Інакше старі помилки можуть непомітно споживати пропускну здатність, призначену для нових відправлень.

Масштабуйте приймання вебхуків незалежно

Якщо провайдер пропонує відповідні вебхуки, вони можуть зменшити кількість повторних запитів статусу. Водночас вони створюють окреме вхідне навантаження, яке має залишатися доступним під час сплесків оновлень.

Зосередьте кінцеву точку приймання на основних діях: перевірте запит за задокументованим провайдером механізмом, надійно збережіть подію та поверніть необхідне підтвердження. Зміни замовлень, аналітику та повідомлення клієнтам обробляйте асинхронно. Не підтверджуйте отримання до надійного приймання, якщо це може призвести до втрати події.

Проєктуйте споживачів так, щоб вони витримували дубльовані доставки, якщо контракт провайдера прямо не встановлює інше. Для дедуплікації надавайте перевагу задокументованому стабільному ідентифікатору події. Якщо його немає, ретельно спроєктуйте та протестуйте складений ідентифікатор: використання лише позначки статусу може об’єднати різні події в одну.

Також захищайтеся від оновлень, що надходять не по порядку. Зберігайте історію подій окремо від похідного поточного стану відправлення. Застосовуйте задокументовані часові позначки подій і правила переходів, якщо вони доступні; не припускайте, що порядок надходження є порядком подій або що статуси відправлення утворюють універсально зростаючу послідовність.

Проводьте цільову звірку з обмеженням швидкості. Вона може досліджувати підозрювані пропуски доставки або неоднозначні реєстрації, але агресивне опитування кожного відправлення може відтворити вихідне навантаження, якого вебхуки мали допомогти уникнути.

Тестуйте відновлення, а не лише максимальну пропускну здатність

Проводьте навантажувальні тести власних компонентів за допомогою симулятора провайдера. Координуйте тести, що надсилають значний трафік до реального провайдера, і дотримуйтеся дозволених обмежень. Успішний тест має продемонструвати, що система повертається до нормального стану після збою, а не лише приймає великий сплеск.

  • Відтворіть сплеск, характерний для складу, після якого надходить звичайний безперервний трафік.
  • Введіть відповіді з обмеженням швидкості, підвищену затримку та тимчасові серверні збої.
  • Імітуйте часткову відмову пакетної обробки та тайм-аут після приймання на стороні сервера.
  • Надсилайте дубльовані вебхук-події та події не по порядку.
  • Переривайте доступ до бази даних і перевіряйте, що неприйняті події помилково не підтверджуються.
  • Запускайте зворотне заповнення паралельно з поточними реєстраціями та перевіряйте справедливість.
  • Повторно відтворюйте елементи з черги недоставлених повідомлень, не обходячи контроль швидкості.

Відстежуйте вік найстарішої придатної реєстрації, затримку приймання, частку успішних записів, частоту обмежень швидкості, обсяг повторних спроб, затримку обробки вебхуків і зростання черги недоставлених повідомлень. Самого розміру черги недостатньо: велика черга може швидко спорожніти, тоді як мала може містити кілька критично важливих відправлень, для яких повторюються невдалі спроби.

До початку пікового сезону розподіліть операційну відповідальність. Інженерна команда має відповідати за контроль диспетчеризації та інструменти відновлення; відповідальний за інтеграцію має підтвердити доступні умови провайдера; операційна команда має визначити, які відправлення отримують пріоритет. Задокументуйте, коли призупиняти імпорти, запитувати додаткову пропускну здатність або досліджувати відсутні оновлення. Найкраща система — та, що залишається передбачуваною, коли трафік перевищує її безпосередню пропускну здатність обробки.

Поширені запитання

Чи збільшить додавання ключів API пропускну здатність?

Не обов’язково. Кілька ключів можуть використовувати спільний ліміт на рівні облікового запису. Підтвердьте область обмеження та дозволений спосіб масштабування у провайдера. Не використовуйте ротацію ключів для обходу обмежень.

Чи має кожна реєстрація використовувати найбільший можливий пакет?

Ні. Більші пакети можуть підвищити ефективність запитів, але очікування їх заповнення збільшує затримку за низького обсягу. Використовуйте задокументовану максимальну кількість записів і таймер відправлення, а потім налаштовуйте систему за виміряною затримкою приймання та поведінкою під час збоїв.

Як запобігти дубльованим реєстраціям після тайм-ауту?

Використовуйте надійний локальний ідентифікатор відправлення та задокументовану провайдером поведінку ідемпотентності або обробки дублікатів. Якщо результат залишається невизначеним, виконайте доступну звірку перед повторним відтворенням. Одна лише локальна дедуплікація не може довести, чи був віддалений запит успішним.

Чи означає успішна реєстрація, що інформація про відстеження актуальна?

Ні. Приймання реєстрації, доступність події перевізника, обробка провайдером і власна обробка оновлення — окремі етапи. Вимірюйте їх окремо, щоб затримку сканування перевізником не було помилково сприйнято як чергу реєстрації.

Коли команда має запитувати додаткову пропускну здатність у провайдера?

Запитуйте її, коли прогнозовані надходження та необхідний час відновлення перевищують перевірену доступну пропускну здатність після усунення повторних спроб, дубльованих надсилань і неефективної пакетної обробки, яких можна уникнути. Більший ліміт не виправить заблокованого споживача або вузьке місце в базі даних, тому спочатку визначте визначальне обмеження.

Джерела

Loading