Скалабилност на Tracking API: Како да се справите со обемот во шпицот на сезоната, ограничувањата на стапката и масовната регистрација

За да го зголемите капацитетот на API за следење во периодот на најголема сезона, ставете ја регистрацијата на пратките зад издржлива редица, спроведете ги ограничувањата на провајдерот кај сите работници, групирајте ги записите само во рамките на документираните ограничувања и обработувајте ги ажурирањата за следење асинхроно. Третирајте ги пропусната моќ на регистрацијата, сообраќајот од повторни обиди и обработката на webhook-ите како одделни проблеми со капацитетот. Додавањето повеќе работници без контрола на излезните барања може да го зголеми ограничувањето наместо да ја намали заостанатата работа.

За инженерските тимови што поврзуваат систем за управување со нарачки, магацинска платформа или backend за е-трговија со услуга за следење, целта не е едноставно да се испратат повеќе барања. Целта е пратките да се регистрираат во дефиниран временски интервал, да се зачуваат ажурирањата за време на сообраќајни пикови и да се обнови работата по грешки без создавање дупликатна работа.

Димензионирајте го обемот околу пратките, барањата и ажурирањата

Дневниот обем на пратки не е доволен за димензионирање на интеграцијата. Магацинот може да ги ослободи повеќето броеви за следење во краток временски интервал за испорака, додека ажурирањата на статусот пристигнуваат во текот на целиот ден. Моделирајте ги овие оптоварувања одделно.

• Пристигнувања на регистрации: Нови записи за пратки што влегуваат во вашиот систем во секунда или минута, вклучувајќи увози и пикови при ослободување од магацинот.
• Излезен API сообраќај: Барања за регистрација, пребарувања, корекции, повици за усогласување и повторни обиди.
• Влезен сообраќај од ажурирања: Испораки и повторни испораки на webhook-и, кога провајдерот ги поддржува.
• Работа во надолниот тек: Записи во базата на податоци, известувања до клиентите, аналитички настани и промени на статусот на нарачките предизвикани од секое ажурирање.

Поставете интерна цел за регистрација, како што е максималното прифатливо време помеѓу приемот на бројот за следење и потврдата на неговата регистрација. Чувајте ја одделно од свежината на следењето: успешната регистрација не значи дека скенирањето од превозникот веќе е достапно.

Пресметајте го ефективниот капацитет за регистрација

За крајна точка за регистрација ограничена со бројот на барања, корисна релација за планирање е:

Капацитет за регистрација = дозволени барања во секунда × просечен број записи по барање × удел на успешно запишани записи

Ова е проценка за планирање, а не гаранција од провајдерот. Таа претпоставува дека ограничувањето на барањата е главниот ограничувачки фактор. Квотите засновани на записи, големината на payload-от, латентноста и споделените ограничувања на сметката може да наметнат пониска горна граница.

Само за илустрација, да претпоставиме дека една интеграција има дозвола за две барања за регистрација во секунда и испраќа просечно 30 записи во секое барање. Нејзиниот номинален капацитет е 60 записи во секунда пред грешките и другите ограничувања. Ако просечниот прилив на регистрации е 80 записи во секунда за време на продолжен пик, редицата расте за приближно 20 записи во секунда. Овие бројки се хипотетички, а не ограничувања на 17TRACK.

Пресметајте го и капацитетот за опоравување. Ако новите пристигнувања продолжат со стапка λ, а ефективниот капацитет за обработка е μ, постоечката заостаната работа од B записи се расчистува за приближно B / (μ − λ) секунди кога μ > λ. Ако капацитетот за обработка не го надминува приливот, заостанатата работа нема да се расчисти во тие услови.

Потврдете што всушност ограничува провајдерот

Ограничувањето на стапката и дозволениот обем на користење решаваат различни проблеми. Ограничувањето на стапката контролира колку брзо може да се испраќаат барања или записи. Дозволениот обем на користење може да контролира колкава активност за следење може да потроши сметката во текот на периодот на наплата или важност на претплатата. Тоа што сте под едното не докажува усогласеност со другото.

Пред да го поставите бројот на работници, потврдете го следново во документацијата на провајдерот и условите на вашата сметка:

• Дали ограничувањата важат по сметка, API клуч, крајна точка, IP адреса или друг опсег.
• Дали единицата што се брои е барање, запис за следење или друга операција.
• Дали крајните точки делат едно ограничување или имаат независни дозволи.
• Максималниот број записи и големината на payload-от дозволени во едно барање.
• Како дупликатните испраќања, невалидните записи и повторните обиди влијаат врз користењето.
• Дали одговорите содржат информации за ограничување или насоки за повторен обид.
• Како исцрпувањето на квотата се разликува од привременото ограничување.

За интеграција со 17TRACK, користете ја официјалната страница на Tracking API и API документацијата како почетни точки за оваа конфигурација. Потврдете го применливото однесување на крајната точка и ограничувањата на сметката пред пуштање во продукција. Примерите за капацитет во ова упатство се илустрации за архитектура, а не изјави за дозволите, големините на групите или гаранциите за услугата на 17TRACK.

Поставете издржлива редица помеѓу обработката на нарачките и регистрацијата

Не дозволувајте завршувањето на наплатата или магацинската операција да чека провајдерот за следење да прифати регистрација. Зачувајте ја пратката локално, трајно запишете ја задачата за регистрација и дозволете им на работниците во заднина да го извршат испраќањето.

Практичниот тек е:

1. Зачувајте ја пратката и нејзината намера за регистрација. Користете transactional outbox или еквивалентен дизајн за да избегнете зачувување на нарачката без задачата во заднина.
2. Потврдете ги и нормализирајте ги влезовите. Зачувајте ги броевите за следење како низи, вклучувајќи ги и почетните нули. Применувајте нормализација специфична за превозникот само кога е оправдана.
3. Проверете дали веќе постои регистрација. Користете стабилен идентитет соодветен за провајдерот и вашиот модел на податоци.
4. Ставете ги подобните записи во редица. Зачувајте го бројот на обиди, времето на следниот дозволен повторен обид и доволно контекст за дијагностика.
5. Испраќајте преку споделен ограничувач. Преземете капацитет непосредно пред излезното барање.
6. Трајно зачувајте ги резултатите на ниво на запис. Одделете потврдени успеси, грешки за кои е можен повторен обид, трајни одбивања и нејасни резултати.

Редицата апсорбира пик; таа не создава капацитет кај провајдерот. Ако најстариот подобен запис постојано старее, истражете ја разликата помеѓу стапката на пристигнување и капацитетот за обработка наместо едноставно да го зголемувате бројот на работници.

Координирајте ги ограничувањата кај работниците

Независните работници не смеат секој поединечно да претпоставуваат дека можат да ја искористат целата дозвола на сметката. Користете координиран ограничувач на стапката или диспечер што распределува споделен буџет за барања. Во тој буџет вклучете ги планираните увози, оперативните скрипти и задачите за усогласување.

Стапката и конкурентноста се различни контроли. Ограничувачот контролира колку често започнуваат барањата; ограничувањето на конкурентноста контролира колку барања остануваат во тек. Двете се корисни кога расте латентноста кај провајдерот. Зголемувањето на конкурентноста може да помогне кај оптоварување ограничено со латентност, но не може да го надмине ограничувањето на излезната стапка.

Користете групна регистрација без да ја изгубите контролата на ниво на запис

Кога крајната точка поддржува повеќе записи по барање, групирањето може да го намали трошокот од барањата. Тоа не мора да го намали користењето засновано на записи, а најголемата дозволена група не е секогаш најдобриот оперативен избор.

Создавајте групи со два активирачки услови: максимален број записи и максимално време на чекање. Испратете ја групата кога ќе се достигне кој било од нив. Така, за време на најоптоварените периоди групите се полнат ефикасно, без сообраќајот со мал обем да чека неограничено.

• Почитувајте ги ограничувањата на payload-от, како и бројот на записи. Опционалните метаподатоци може да направат групи со ист број записи да се разликуваат значително по големина во бајти.
• Чувајте интерен манифест на групата. Запишете кои локални идентитети на пратки се испратени и правилно поврзете го секој добиен резултат.
• Проверувајте ги резултатите на апликативно ниво. Успешниот HTTP одговор сам по себе не докажува дека секој запис е прифатен.
• Повторувајте ги само записите на кои им е потребен повторен обид. Повторното испраќање на успешните записи создава непотребен сообраќај и може да има последици врз користењето.
• Пренасочете ги трајните грешки при валидација кон корекција. Непроменетиот невалиден payload не треба да кружи низ редицата за повторни обиди.

Особено важен е timeout-от: провајдерот можеби го прифатил барањето иако вашиот клиент не го добил одговорот. Означете го тој исход како нејасен. Разјаснете го преку поддржан механизам за идемпотентност, документирано правило за дупликатна регистрација или пребарување за усогласување, каде што е достапно. Не претпоставувајте дека запишувањето не успеало само затоа што истекло времето.

Одделете го тековниот сообраќај од историските увози

Пополнувањето на историски податоци не треба да го потроши целиот капацитет потребен за новоиспратените пратки. Користете одделни редици со пондерирано распоредување или со експлицитно резервирање капацитет. Дозволете им на увозите да го користат слободниот капацитет, а истовремено зачувајте минимална распределба за тековните регистрации. Применувајте стареење или друго правило за правичност за записите со понизок приоритет на крајот да бидат обработени.

Направете ги повторните обиди контролирани, одложени и ограничени

HTTP 429 значи „Премногу барања“. RFC 6585 наведува дека одговорот 429 може да содржи заглавие Retry-After. RFC 9110 ја дефинира вредноста на тоа заглавие како HTTP датум или доцнење во секунди. Клиентот треба да ги обработува двата формати, наместо секогаш да претпоставува дека се враќа цел број.

Кога е дадено валидно доцнење за повторен обид, не обидувајте се повторно пред неговото истекување. Кога нема насоки за повторен обид, користете ограничено експоненцијално повратно доцнење со случајна компонента: постепено зголемувајте го доцнењето помеѓу обидите и додавајте случајност за работниците да не се обидуваат повторно истовремено. Повторните обиди мора да поминуваат низ истиот излезен ограничувач како и првичните обиди.

Класифицирајте ги грешките пред повторниот обид:

• Ограничување: Одложете ја погодената работа и намалете го притисокот при испраќање во рамките на релевантниот опсег на ограничување.
• Привремени мрежни или серверски грешки: Повторете го обидот во рамките на ограничена политика, земајќи ги предвид нејасните исходи на запишувањето.
• Грешки при автентикација или авторизација: Испратете предупредување и паузирајте ја погодената работа додека не се поправат акредитивите или дозволите.
• Грешки при валидација: Поправете го или изолирајте го записот наместо повторно да го испраќате непроменет.
• Исцрпена дозвола: Следете го документираниот лек за сметката наместо да го третирате проблемот како краткотраен сообраќаен пик.

Поставете и ограничување на бројот на обиди и максимална старост за повторните обиди. Преместете ги исцрпените ставки во dead-letter редица со причина, сопственик и постапка за повторно пуштање. Во спротивно, старите грешки може тивко да го трошат капацитетот наменет за новите пратки.

Зголемувајте го капацитетот за прием на webhook-и независно

Кога провајдерот нуди соодветни webhook-и, тие може да го намалат повтореното пребарување на статусот. Но, тие создаваат и одделно влезно оптоварување што мора да остане достапно за време на пикови во ажурирањата.

Одржувајте ја крајната точка за прием фокусирана: потврдете го барањето со користење на документираниот механизам на провајдерот, трајно зачувајте го настанот и вратете ја потребната потврда. Обработувајте ги промените на нарачките, аналитиката и пораките до клиентите асинхроно. Не потврдувајте прием пред трајното прифаќање ако тоа би создало ризик од губење на настанот.

Дизајнирајте ги потрошувачите да толерираат дупликатна испорака, освен ако договорот со провајдерот изречно не утврдува поинаку. Претпочитајте документиран стабилен идентификатор на настанот за отстранување дупликати. Ако таков не постои, внимателно дизајнирајте и тестирајте сложен идентитет: користењето само на ознака за статус може да спои различни настани во еден.

Заштитете се и од ажурирања што пристигнуваат по погрешен редослед. Чувајте ја историјата на настаните одделно од изведената тековна состојба на пратката. Каде што е достапно, применувајте ги документираните временски ознаки на настаните и правилата за премин; не претпоставувајте дека редоследот на пристигнување е редослед на настаните или дека статусите на пратката формираат универзално растечка низа.

Одржувајте го усогласувањето насочено и ограничено според стапката. Тоа може да ги истражи сомнителните празнини во испораката или нејасните регистрации, но агресивното пребарување на секоја пратка може повторно да го создаде излезното оптоварување што webhook-ите требаше да го избегнат.

Тестирајте го опоравувањето, а не само максималната пропусна моќ

Извршувајте тестови на оптоварување врз сопствените компоненти со користење симулатор на провајдерот. Координирајте ги тестовите што испраќаат значителен сообраќај до активен провајдер и останете во рамките на овластените ограничувања. Успешниот тест треба да покаже дека системот се враќа во нормала по прекин, а не само дека прифаќа голем пик.

• Повторете пик сличен на оној во магацин, проследен со продолжен нормален сообраќај.
• Внесете одговори со ограничување, зголемена латентност и привремени серверски грешки.
• Симулирајте делумно одбивање на група и timeout по прифаќањето на серверот.
• Испратете дупликатни webhook настани и настани со погрешен редослед.
• Прекинете го пристапот до базата на податоци и потврдете дека неприфатените настани не се лажно потврдени.
• Извршете пополнување на историски податоци паралелно со тековните регистрации и проверете ја правичноста.
• Повторно пуштете ги ставките од dead-letter редицата без заобиколување на контролите на стапката.

Следете ја староста на најстарата подобна регистрација, латентноста до прифаќање, стапката на успех на ниво на запис, зачестеноста на ограничувањата, обемот на повторните обиди, заостанувањето во обработката на webhook-ите и растот на dead-letter редицата. Самата длабочина на редицата не е доволна: голема редица може брзо да се испразни, додека мала редица може да содржи неколку постојано неуспешни, деловно критични пратки.

Пред сезоната на најголема побарувачка, определете оперативна одговорност. Инженерството треба да ги поседува контролите за испраќање и алатките за опоравување; сопственикот на интеграцијата треба да ги потврди дозволите кај провајдерот; оперативниот тим треба да дефинира кои пратки имаат приоритет. Документирајте кога да се паузираат увозите, да се побара дополнителен капацитет или да се истражат пропуштените ажурирања. Најдобар е дизајнот што останува предвидлив кога сообраќајот го надминува неговиот моментален капацитет за обработка.

ЧПП

Дали додавањето API клучеви ќе ја зголеми пропусната моќ?

Не нужно. Повеќе клучеви може да делат дозвола на ниво на сметка. Потврдете го опсегот на ограничувањето и дозволениот пристап за зголемување на капацитетот со провајдерот. Не користете ротација на клучеви за заобиколување на ограничувањата.

Дали секоја регистрација треба да ја користи најголемата можна група?

Не. Поголемите групи може да ја подобрат ефикасноста на барањата, но чекањето за нивно пополнување ја зголемува латентноста при мал обем. Користете документирана горна граница за големината и тајмер за испраќање, а потоа прилагодувајте врз основа на измерената латентност до прифаќање и однесувањето при грешки.

Како може да се спречат дупликатни регистрации по timeout?

Користете траен локален идентитет на пратката и документираното однесување на провајдерот за идемпотентност или постапување со дупликати. Ако исходот остане неизвесен, извршете усогласување каде што е поддржано пред повторното испраќање. Самото локално отстранување дупликати не може да докаже дали оддалеченото барање успеало.

Дали успешната регистрација значи дека информациите за следење се ажурни?

Не. Прифаќањето на регистрацијата, достапноста на настанот од превозникот, обработката кај провајдерот и вашата сопствена обработка на ажурирањата се одделни фази. Мерете ги одделно за да не се помеша задоцнетото скенирање од превозникот со заостаната регистрација.

Кога тимот треба да побара поголем капацитет од провајдерот?

Побарајте го кога предвидените пристигнувања и потребното време за опоравување го надминуваат потврдениот употреблив капацитет, откако ќе ги отстраните непотребните повторни обиди, дупликатните испраќања и неефикасното групирање. Поголема дозвола нема да го поправи блокираниот потрошувач или тесното грло во базата на податоци, затоа прво идентификувајте го ограничувачкиот фактор.

Извори

• 17TRACK Tracking API — официјална почетна точка за понудата на API.
• 17TRACK API documentation — референца за проверка на барањата за интеграција, однесувањето на крајните точки и применливите ограничувања на барањата.
• RFC 6585, Section 4: 429 Too Many Requests — семантика на HTTP ограничувањето и опционални насоки за Retry-After.
• RFC 9110, Section 10.2.3: Retry-After — формати HTTP-date и delay-seconds.
• RFC 9110, Section 9.2.2: Idempotent Methods — размислувања за повторен обид кога исходот од барањето е неизвесен.