DomůBlogŠkálovatelnost Tracking API: Jak zvládnout objem během hlavní sezóny, rychlostní limity a hromadnou registraci

Škálovatelnost Tracking API: Jak zvládnout objem během hlavní sezóny, rychlostní limity a hromadnou registraci

17TRACK

Chcete-li škálovat tracking API pro hlavní sezónu, umístěte registraci zásilek za odolnou frontu, vynucujte limity poskytovatele napříč všemi workery, dávkujte pouze v rámci zdokumentovaných limitů a zpracovávejte aktualizace sledování asynchronně. Kapacitu registrace, provoz opakovaných pokusů a zpracování webhooků považujte za samostatné kapacitní problémy. Přidání dalších workerů bez kontroly odchozích požadavků může zvýšit omezování rychlosti namísto vyprázdnění backlogu.

Škálovatelnost Tracking API: jak zvládnout objem v hlavní sezóně

Pro technické týmy, které připojují systém pro správu objednávek, skladovou platformu nebo ecommerce backend ke službě sledování, není cílem pouze odesílat více požadavků. Cílem je zaregistrovat zásilky v definovaném časovém okně, zachovat aktualizace během špiček provozu a zotavit se z chyb bez vytváření duplicitní práce.

Dimenzujte zátěž podle zásilek, požadavků a aktualizací

Denní objem zásilek k dimenzování integrace nestačí. Sklad může uvolnit většinu sledovacích čísel během krátkého expedičního okna, zatímco aktualizace stavů přicházejí po celý den. Tyto zátěže modelujte odděleně.

  • Příchozí registrace: Nové záznamy zásilek vstupující do vašeho systému za sekundu nebo minutu, včetně importů a špiček při uvolnění ze skladu.
  • Odchozí provoz API: Registrační požadavky, vyhledávání, opravy, rekonciliační volání a opakované pokusy.
  • Příchozí provoz aktualizací: Doručení webhooků a jejich opakovaná doručení, pokud je poskytovatel podporuje.
  • Navazující práce: Zápisy do databáze, upozornění zákazníků, analytické události a změny stavu objednávek vyvolané každou aktualizací.

Stanovte interní cíl registrace, například maximální přijatelnou dobu mezi přijetím sledovacího čísla a potvrzením jeho registrace. Tento cíl udržujte odděleně od aktuálnosti sledování: úspěšná registrace neznamená, že je již k dispozici sken přepravce.

Výpočet efektivní kapacity registrace

Pro registrační endpoint omezený počtem požadavků je užitečný tento plánovací vztah:

Kapacita registrace = povolené požadavky za sekundu × průměrný počet záznamů na požadavek × podíl úspěšných záznamů

Jde o plánovací odhad, nikoli o záruku poskytovatele. Předpokládá, že rozhodujícím omezením jsou limity požadavků. Nižší strop mohou stanovit kvóty založené na počtu záznamů, velikost dat, latence a sdílené limity účtu.

Pouze pro ilustraci předpokládejme, že integrace smí odeslat dva registrační požadavky za sekundu a v každém požadavku posílá průměrně 30 záznamů. Její nominální kapacita je před započtením chyb a dalších omezení 60 záznamů za sekundu. Pokud příchozí registrace během trvalé špičky dosahují v průměru 80 záznamů za sekundu, fronta roste přibližně o 20 záznamů za sekundu. Tato čísla jsou hypotetická a nepředstavují limity 17TRACK.

Vypočítejte také kapacitu zotavení. Pokud nové příchozí záznamy pokračují rychlostí λ a efektivní kapacita zpracování je μ, existující backlog B záznamů se při μ > λ vyprázdní přibližně za B / (μ − λ) sekund. Pokud kapacita zpracování nepřevyšuje počet příchozích záznamů, backlog se za těchto podmínek nevyprázdní.

Ověřte, co poskytovatel skutečně omezuje

Rate limit a objemová kvóta řeší odlišné problémy. Rate limit řídí, jak rychle lze odesílat požadavky nebo záznamy. Objemová kvóta může určovat, kolik sledovací aktivity může účet spotřebovat během fakturačního nebo přiděleného období. Dodržení jednoho neznamená dodržení druhého.

Před nastavením počtu workerů ověřte v dokumentaci poskytovatele a ve smluvních podmínkách účtu následující:

  • Zda limity platí pro účet, API klíč, endpoint, IP adresu nebo jiný rozsah.
  • Zda se počítá požadavek, sledovací záznam nebo jiná operace.
  • Zda endpointy sdílejí limit, nebo mají nezávislé kvóty.
  • Maximální počet záznamů a velikost dat povolené v jednom požadavku.
  • Jak duplicitní odeslání, neplatné záznamy a opakované pokusy ovlivňují využití.
  • Zda odpovědi poskytují informace o omezování rychlosti nebo pokyny k opakování.
  • V čem se vyčerpání kvóty liší od dočasného omezování rychlosti.

Pro integraci 17TRACK použijte jako výchozí body oficiální stránku Tracking API a dokumentaci API. Před nasazením ověřte chování příslušného endpointu a limity účtu. Příkladové kapacity v této příručce jsou ilustracemi architektury, nikoli tvrzeními o oprávněních 17TRACK, velikostech dávek nebo zárukách služby.

Vložte mezi zpracování objednávek a registraci odolnou frontu

Nenechávejte checkout ani dokončení skladové operace čekat na přijetí registrace poskytovatelem sledování. Uložte zásilku lokálně, trvale zaznamenejte registrační úlohu a nechte její odeslání obsluhovat workery na pozadí.

Praktický postup:

  1. Uložte zásilku a záměr její registrace. Použijte transakční outbox nebo ekvivalentní návrh, abyste zabránili uložení objednávky bez uložení úlohy na pozadí.
  2. Ověřte a normalizujte vstupy. Sledovací čísla uchovávejte jako řetězce včetně počátečních nul. Normalizaci specifickou pro přepravce používejte pouze tehdy, když je odůvodněná.
  3. Ověřte existující registraci. Použijte stabilní identitu odpovídající poskytovateli a vašemu datovému modelu.
  4. Zařaďte způsobilé záznamy do fronty. Ukládejte počet pokusů, čas dalšího způsobilého opakování a dostatek kontextu pro diagnostiku.
  5. Odesílejte prostřednictvím sdíleného limiteru. Kapacitu rezervujte bezprostředně před odchozím požadavkem.
  6. Trvale ukládejte výsledky na úrovni záznamů. Oddělujte potvrzený úspěch, opakovatelnou chybu, trvalé odmítnutí a nejednoznačné výsledky.

Fronta absorbuje špičku, ale nevytváří kapacitu poskytovatele. Pokud se stáří nejstaršího způsobilého záznamu stále zvyšuje, zkoumejte rozdíl mezi rychlostí příchozích záznamů a kapacitou zpracování, místo abyste pouze zvyšovali počet workerů.

Koordinujte limity napříč workery

Nezávislí workeři nesmějí každý předpokládat, že může spotřebovat celý limit účtu. Použijte koordinovaný rate limiter nebo dispečer, který přiděluje sdílený rozpočet požadavků. Do tohoto rozpočtu zahrňte plánované importy, provozní skripty a rekonciliační úlohy.

Rychlost a souběžnost jsou různé mechanismy řízení. Limiter určuje, jak často požadavky začínají; limit souběžnosti určuje, kolik požadavků zůstává právě zpracováváno. Oba mechanismy jsou užitečné při růstu latence poskytovatele. Zvýšení souběžnosti může pomoci zátěži omezené latencí, nemůže však obejít limit odchozí rychlosti.

Používejte hromadnou registraci, aniž byste ztratili kontrolu na úrovni záznamů

Pokud endpoint podporuje více záznamů v jednom požadavku, dávkování může snížit režii požadavků. Nemusí však snížit využití založené na počtu záznamů a největší povolená dávka není vždy provozně nejlepší volbou.

Dávky vytvářejte pomocí dvou spouštěčů: maximálního počtu záznamů a maximální doby čekání. Odešlete je, jakmile je splněna kterákoli podmínka. Vytížená období tak efektivně naplní dávky, zatímco provoz s nízkým objemem nebude čekat neomezeně dlouho.

  • Respektujte limity dat stejně jako počet záznamů. Volitelná metadata mohou způsobit, že stejně velké dávky se budou výrazně lišit počtem bajtů.
  • Udržujte interní manifest dávky. Zaznamenávejte, které lokální identity zásilek byly odeslány, a správně k nim přiřazujte vrácené výsledky.
  • Kontrolujte výsledky na úrovni aplikace. Úspěšná odpověď HTTP sama o sobě nedokazuje, že byl přijat každý záznam.
  • Opakujte pouze záznamy, které opakování potřebují. Opětovné odeslání úspěšných záznamů vytváří zbytečný provoz a může mít dopad na využití.
  • Trvalé validační chyby směrujte k opravě. Nezměněné neplatné datové zatížení nemá obíhat frontou opakovaných pokusů.

Zvláště důležitý je timeout: poskytovatel mohl požadavek přijmout, i když klient neobdržel odpověď. Takový výsledek označte jako nejednoznačný. Vyřešte jej pomocí podporovaného mechanismu idempotence, zdokumentovaného pravidla pro duplicitní registrace nebo rekonciliačního vyhledávání, pokud je k dispozici. Nepředpokládejte, že zápis s timeoutem selhal.

Oddělte živý provoz od historických importů

Backfill nesmí spotřebovat veškerou kapacitu potřebnou pro nově expedované zásilky. Použijte oddělené fronty s váženým plánováním nebo explicitními rezervacemi kapacity. Importům dovolte využívat volnou kapacitu a současně zachovejte minimální příděl pro živé registrace. Použijte stárnutí nebo jiné pravidlo spravedlnosti, aby byly záznamy s nižší prioritou nakonec zpracovány.

Opakované pokusy řiďte, odkládejte a omezujte

HTTP 429 znamená „Too Many Requests“. RFC 6585 uvádí, že odpověď 429 může obsahovat hlavičku Retry-After. RFC 9110 definuje její hodnotu buď jako datum HTTP, nebo prodlevu v sekundách. Klient by měl zpracovat obě formy, nikoli předpokládat, že je vždy vráceno celé číslo.

Pokud je uvedena platná prodleva pro opakování, neopakujte požadavek před jejím uplynutím. Pokud pokyny k opakování chybí, použijte omezený exponenciální backoff s jitterem: postupně prodlužujte prodlevu mezi pokusy a přidejte náhodnost, aby se workeři nepokoušeli opakovat požadavek současně. Opakované pokusy musí procházet stejným limiterem odchozího provozu jako první pokusy.

Před opakováním klasifikujte chyby:

  • Omezování rychlosti: Odložte dotčenou práci a snižte tlak na odesílání v rámci příslušného rozsahu limitu.
  • Dočasné síťové nebo serverové chyby: Opakujte podle omezené zásady a zohledněte nejednoznačné výsledky zápisu.
  • Chyby autentizace nebo autorizace: Upozorněte a pozastavte dotčenou práci, dokud nebudou opraveny přihlašovací údaje nebo oprávnění.
  • Validační chyby: Záznam opravte nebo izolujte, místo abyste jej posílali znovu beze změny.
  • Vyčerpaná kvóta: Postupujte podle zdokumentovaného řešení účtu, nikoli jako při krátkodobé špičce provozu.

Nastavte limit počtu pokusů i maximální stáří opakování. Vyčerpané položky přesuňte do dead-letter fronty s uvedením důvodu, vlastníka a postupu opětovného přehrání. Jinak mohou staré chyby tiše spotřebovávat kapacitu určenou pro nové zásilky.

Škálujte příjem webhooků nezávisle

Pokud poskytovatel nabízí vhodné webhooky, mohou omezit opakované dotazování na stav. Vytvářejí však také samostatnou příchozí zátěž, která musí zůstat dostupná během špiček aktualizací.

Přijímací endpoint udržujte úzce zaměřený: ověřte požadavek pomocí mechanismu zdokumentovaného poskytovatelem, trvale událost uložte a vraťte požadované potvrzení. Změny objednávek, analytiku a zprávy zákazníkům zpracovávejte asynchronně. Pokud by hrozila ztráta události, nepotvrzujte její přijetí před trvalým přijetím.

Navrhněte konzumenty tak, aby tolerovali duplicitní doručení, pokud smlouva s poskytovatelem výslovně nestanoví opak. Pro deduplikaci preferujte zdokumentovaný stabilní identifikátor události. Pokud neexistuje, pečlivě navrhněte a otestujte složenou identitu: použití samotného označení stavu může sloučit odlišné události do jedné.

Chraňte se také před aktualizacemi mimo pořadí. Historii událostí ukládejte odděleně od odvozeného aktuálního stavu zásilky. Pokud jsou k dispozici, používejte zdokumentovaná časová razítka událostí a pravidla přechodů; nepředpokládejte, že pořadí doručení je pořadím událostí nebo že stavy zásilky tvoří univerzálně rostoucí posloupnost.

Rekonciliaci udržujte cílenou a omezenou rychlostí. Může zkoumat podezřelé mezery v doručení nebo nejednoznačné registrace, ale agresivní dotazování na každou zásilku může znovu vytvořit odchozí zátěž, které se webhooky měly vyhnout.

Testujte zotavení, nejen maximální propustnost

Zátěžové testy vlastních komponent provádějte pomocí simulátoru poskytovatele. Testy, které odesílají významný provoz skutečnému poskytovateli, koordinujte a zůstaňte v rámci autorizovaných limitů. Úspěšný test by měl prokázat, že se systém po narušení vrátí do normálu, nikoli pouze to, že přijme velkou špičku.

  • Přehrajte špičku ve stylu skladového provozu následovanou pokračujícím běžným provozem.
  • Vložte odpovědi s omezováním rychlosti, zvýšenou latencí a dočasnými chybami serveru.
  • Simulujte částečné odmítnutí dávky a timeout po přijetí na straně serveru.
  • Doručte duplicitní webhookové události i události mimo pořadí.
  • Přerušte přístup k databázi a ověřte, že nepřijaté události nejsou chybně potvrzeny.
  • Spusťte backfill současně s živými registracemi a ověřte spravedlnost.
  • Přehrajte položky z dead-letter fronty, aniž byste obešli řízení rychlosti.

Sledujte stáří nejstarší způsobilé registrace, latenci přijetí, úspěšnost na úrovni záznamů, četnost omezování rychlosti, objem opakovaných pokusů, zpoždění zpracování webhooků a růst dead-letter fronty. Samotná hloubka fronty nestačí: velká fronta se může rychle vyprázdnit, zatímco malá fronta může obsahovat několik opakovaně selhávajících, obchodně kritických zásilek.

Před hlavní sezónou určete provozní odpovědnosti. Engineering by měl vlastnit řízení odesílání a nástroje pro zotavení; vlastník integrace by měl potvrdit oprávnění u poskytovatele; provoz by měl definovat, které zásilky mají prioritu. Zdokumentujte, kdy pozastavit importy, požádat o dodatečnou kapacitu nebo prověřit chybějící aktualizace. Nejlepší návrh je takový, který zůstává předvídatelný, když provoz překročí okamžitou kapacitu zpracování.

Často kladené otázky

Zvýší přidání API klíčů propustnost?

Ne nutně. Více klíčů může sdílet kvótu na úrovni účtu. Ověřte rozsah limitu a povolený způsob škálování u poskytovatele. Nepoužívejte rotaci klíčů k obcházení omezení.

Měla by každá registrace používat největší možnou dávku?

Ne. Větší dávky mohou zlepšit efektivitu požadavků, ale čekání na jejich naplnění zvyšuje latenci při nízkém objemu. Použijte zdokumentovaný limit velikosti spolu s časovačem odeslání a poté nastavení upravujte podle naměřené latence přijetí a chování při chybách.

Jak zabránit duplicitním registracím po timeoutu?

Použijte trvalou lokální identitu zásilky a zdokumentované chování poskytovatele týkající se idempotence nebo duplicit. Pokud výsledek zůstává nejistý, před opětovným odesláním jej podle možností zrekoncilujte. Samotná lokální deduplikace nedokáže prokázat, zda vzdálený požadavek uspěl.

Znamená úspěšná registrace, že jsou informace o sledování aktuální?

Ne. Přijetí registrace, dostupnost události přepravce, zpracování poskytovatelem a vaše vlastní zpracování aktualizace jsou samostatné fáze. Měřte je odděleně, aby opožděný sken přepravce nebyl zaměněn za backlog registrace.

Kdy by měl tým požádat poskytovatele o větší kapacitu?

Požádejte o ni, když předpokládaný počet příchozích záznamů a požadovaná doba zotavení překročí ověřenou využitelnou kapacitu po odstranění zbytečných opakovaných pokusů, duplicitních odeslání a neefektivního dávkování. Větší kvóta nevyřeší zablokovaného konzumenta ani úzké hrdlo v databázi, proto nejprve určete rozhodující omezení.

Zdroje

Loading