DomovBlogŠkálovateľnosť Tracking API: Ako zvládnuť objem počas hlavnej sezóny, limity počtu požiadaviek a hromadnú registráciu

Škálovateľnosť Tracking API: Ako zvládnuť objem počas hlavnej sezóny, limity počtu požiadaviek a hromadnú registráciu

17TRACK

Ak chcete škálovať sledovacie API na sezónne špičky, registráciu zásielok umiestnite za odolný front, vynucujte limity poskytovateľa naprieč všetkými workermi, dávkujte iba v rámci zdokumentovaných limitov a aktualizácie sledovania spracúvajte asynchrónne. Priepustnosť registrácie, opakovanú prevádzku a spracovanie webhookov považujte za samostatné kapacitné problémy. Pridanie ďalších workerov bez kontroly odchádzajúcich požiadaviek môže zvýšiť obmedzovanie namiesto vyprázdnenia vášho backlogu.

Škálovateľnosť sledovacieho API: Ako zvládnuť objem počas sezónnej špičky

Pre technické tímy, ktoré pripájajú systém správy objednávok, skladovú platformu alebo backend elektronického obchodu k službe sledovania, nie je cieľom jednoducho odosielať viac požiadaviek. Ide o registráciu zásielok v stanovenom časovom okne, zachovanie aktualizácií počas dopravných špičiek a zotavenie sa z chýb bez vytvárania duplicitnej práce.

Dimenzujte pracovné zaťaženie podľa zásielok, požiadaviek a aktualizácií

Denný objem zásielok nestačí na dimenzovanie integrácie. Sklad môže uvoľniť väčšinu sledovacích čísel počas krátkeho okna expedície, zatiaľ čo aktualizácie stavu prichádzajú počas celého dňa. Tieto pracovné zaťaženia modelujte oddelene.

  • Príchody registrácií: Nové záznamy zásielok vstupujúce do systému za sekundu alebo minútu vrátane importov a nárazových uvoľnení zo skladu.
  • Odchádzajúca prevádzka API: Registračné požiadavky, vyhľadávania, opravy, zosúlaďovacie volania a opakovania.
  • Prichádzajúca prevádzka aktualizácií: Doručenia webhookov a ich opakované doručenia, ak ich poskytovateľ podporuje.
  • Následná práca: Zápisy do databázy, upozornenia zákazníkov, analytické udalosti a zmeny stavu objednávok vyvolané každou aktualizáciou.

Stanovte interný cieľ registrácie, napríklad maximálny prijateľný čas medzi prijatím sledovacieho čísla a potvrdením jeho registrácie. Tento cieľ udržiavajte oddelený od aktuálnosti sledovania: úspešná registrácia neznamená, že sken dopravcu je už k dispozícii.

Vypočítajte efektívnu kapacitu registrácie

Pre registračný koncový bod s limitom požiadaviek je užitočný tento plánovací vzťah:

Kapacita registrácie = povolené požiadavky za sekundu × priemerný počet záznamov na požiadavku × podiel úspešných záznamov

Ide o plánovací odhad, nie o záruku poskytovateľa. Predpokladá, že limit požiadaviek je rozhodujúcim obmedzením. Kvóty založené na počte záznamov, veľkosť payloadu, latencia a zdieľané limity účtu môžu stanoviť nižší strop.

Len na ilustráciu predpokladajme, že integrácii sú povolené dve registračné požiadavky za sekundu a v každej požiadavke odosiela priemerne 30 záznamov. Jej nominálna kapacita je pred zlyhaniami a ďalšími obmedzeniami 60 záznamov za sekundu. Ak prichádzajúce registrácie počas trvalého náporu dosahujú v priemere 80 záznamov za sekundu, front rastie približne o 20 záznamov za sekundu. Tieto čísla sú hypotetické a nepredstavujú limity 17TRACK.

Vypočítajte aj kapacitu obnovy. Ak nové príchody pokračujú rýchlosťou λ a efektívna kapacita spracovania je μ, existujúci backlog B záznamov sa vyprázdni približne za B / (μ − λ) sekúnd, ak μ > λ. Ak kapacita spracovania neprevyšuje počet príchodov, backlog sa za týchto podmienok nevyprázdni.

Overte, čo poskytovateľ skutočne obmedzuje

Rýchlostný limit a povolený objem používania riešia odlišné problémy. Rýchlostný limit určuje, ako rýchlo možno odosielať požiadavky alebo záznamy. Povolený objem používania môže určovať, koľko sledovacej aktivity môže účet spotrebovať počas fakturačného alebo oprávňovacieho obdobia. Dodržanie jedného neznamená splnenie druhého.

Pred nastavením počtu workerov overte v dokumentácii poskytovateľa a podmienkach svojho účtu:

  • Či sa limity uplatňujú na účet, API kľúč, koncový bod, IP adresu alebo iný rozsah.
  • Či je počítanou jednotkou požiadavka, sledovací záznam alebo iná operácia.
  • Či koncové body zdieľajú limit alebo majú nezávislé povolené objemy.
  • Maximálny počet záznamov a veľkosť payloadu povolené v jednej požiadavke.
  • Ako duplicitné odoslania, neplatné záznamy a opakovania ovplyvňujú používanie.
  • Či odpovede poskytujú informácie o obmedzovaní alebo pokyny na opakovanie.
  • Ako sa vyčerpanie kvóty líši od dočasného obmedzovania.

Pri integrácii 17TRACK použite ako východiskové body oficiálnu stránku Tracking API a dokumentáciu API. Pred nasadením overte správanie príslušného koncového bodu a limity účtu. Príklady kapacít v tejto príručke sú ilustráciami architektúry, nie vyhláseniami o oprávneniach 17TRACK, veľkostiach dávok alebo zárukách služby.

Umiestnite odolný front medzi spracovanie objednávok a registráciu

Nenechajte pokladňu alebo dokončenie skladovej operácie čakať na prijatie registrácie poskytovateľom sledovania. Zásielku uložte lokálne, trvalo zaznamenajte registračnú úlohu a odoslanie nechajte na workerov na pozadí.

Praktický postup:

  1. Uložte zásielku a zámer jej registrácie. Použite transakčný outbox alebo ekvivalentný návrh, aby sa objednávka neuložila bez úlohy na pozadí.
  2. Overte a normalizujte vstupy. Sledovacie čísla uchovávajte ako reťazce vrátane úvodných núl. Normalizáciu špecifickú pre dopravcu používajte iba v odôvodnených prípadoch.
  3. Skontrolujte existujúcu registráciu. Použite stabilnú identitu vhodnú pre poskytovateľa a váš dátový model.
  4. Zaraďte oprávnené záznamy do frontu. Uložte počet pokusov, čas nasledujúceho oprávneného opakovania a dostatok kontextu na diagnostiku.
  5. Odosielajte prostredníctvom zdieľaného limitera. Kapacitu získajte bezprostredne pred odchádzajúcou požiadavkou.
  6. Trvalo ukladajte výsledky na úrovni záznamov. Oddeľte potvrdený úspech, opakovateľné zlyhanie, trvalé odmietnutie a nejednoznačné výsledky.

Front absorbuje nápor, nevytvára však kapacitu poskytovateľa. Ak najstarší oprávnený záznam neustále starne, skúmajte rozdiel medzi rýchlosťou príchodov a kapacitou spracovania namiesto jednoduchého zvyšovania počtu workerov.

Koordinujte limity naprieč workermi

Nezávislí workeri nesmú každý predpokladať, že môžu spotrebovať celý limit účtu. Použite koordinovaný limiter rýchlosti alebo dispečera, ktorý prideľuje zdieľaný rozpočet požiadaviek. Do tohto rozpočtu zahrňte plánované importy, prevádzkové skripty a úlohy zosúladenia.

Rýchlosť a súbežnosť sú odlišné riadiace prvky. Limiter určuje, ako často sa požiadavky spúšťajú; limit súbežnosti určuje, koľko požiadaviek zostáva vo fáze spracovania. Oba prvky sú užitočné, keď rastie latencia poskytovateľa. Zvýšenie súbežnosti môže pomôcť pri pracovnom zaťažení limitovanom latenciou, nemôže však obísť limit odchádzajúcej rýchlosti.

Používajte hromadnú registráciu bez straty kontroly na úrovni záznamov

Ak koncový bod podporuje viac záznamov na požiadavku, dávkovanie môže znížiť režijné náklady na požiadavky. Nemusí však znížiť používanie založené na počte záznamov a najväčšia povolená dávka nie je vždy najlepšou prevádzkovou voľbou.

Dávky vytvárajte pomocou dvoch spúšťačov: maximálneho počtu záznamov a maximálneho času čakania. Odošlite ich, keď sa dosiahne ktorýkoľvek z nich. Počas rušných období sa tak dávky efektívne naplnia bez toho, aby nízkoobjemová prevádzka čakala neobmedzene dlho.

  • Dodržiavajte limity payloadu aj počty záznamov. Voliteľné metadáta môžu spôsobiť, že dávky s rovnakým počtom záznamov budú mať veľmi odlišnú veľkosť v bajtoch.
  • Udržiavajte interný manifest dávky. Zaznamenajte, ktoré lokálne identity zásielok boli odoslané, a správne priraďte každý vrátený výsledok.
  • Kontrolujte výsledky na aplikačnej úrovni. Úspešná odpoveď HTTP sama osebe nedokazuje, že každý záznam bol prijatý.
  • Opakujte iba záznamy, ktoré to potrebujú. Opätovné odoslanie úspešných záznamov vytvára zbytočnú prevádzku a môže mať dôsledky pre používanie.
  • Trvalé validačné zlyhania smerujte na opravu. Nezmenený neplatný payload by nemal obiehať frontom opakovaní.

Obzvlášť dôležitý je timeout: poskytovateľ mohol požiadavku prijať, hoci váš klient nedostal odpoveď. Takýto výsledok označte ako nejednoznačný. Vyriešte ho pomocou podporovaného mechanizmu idempotencie, zdokumentovaného pravidla duplicitnej registrácie alebo vyhľadania zosúladenia, ak je k dispozícii. Nepredpokladajte, že zápis s timeoutom zlyhal.

Oddeľte živú prevádzku od historických importov

Spätné doplnenie údajov by nemalo spotrebovať celú kapacitu potrebnú pre novo expedované zásielky. Použite samostatné fronty s váhovým plánovaním alebo explicitnými rezerváciami kapacity. Importom povoľte využívať voľnú kapacitu a zároveň zachovajte minimálnu alokáciu pre živé registrácie. Použite starnutie alebo iné pravidlo spravodlivosti, aby sa záznamy s nižšou prioritou napokon spracovali.

Riadené, oneskorené a ohraničené opakovania

HTTP 429 znamená „Too Many Requests“. RFC 6585 uvádza, že odpoveď 429 môže obsahovať hlavičku Retry-After. RFC 9110 definuje hodnotu tejto hlavičky buď ako dátum HTTP, alebo oneskorenie v sekundách. Klient by mal analyzovať oba formáty a nemal by predpokladať, že sa vždy vráti celé číslo.

Ak je poskytnuté platné oneskorenie opakovania, neopakujte požiadavku pred jeho uplynutím. Ak pokyny na opakovanie chýbajú, použite exponenciálne oneskorenie s horným limitom a jitterom: postupne predlžujte oneskorenie medzi pokusmi a pridajte náhodnosť, aby všetci workeri neopakovali požiadavky naraz. Opakovania musia prechádzať rovnakým limiterom odchádzajúcej prevádzky ako prvé pokusy.

Pred opakovaním klasifikujte zlyhania:

  • Obmedzovanie: Odložte dotknutú prácu a znížte tlak odosielania v rámci príslušného rozsahu limitu.
  • Dočasné sieťové alebo serverové zlyhania: Opakujte v rámci ohraničenej politiky a zohľadnite nejednoznačné výsledky zápisu.
  • Zlyhania autentifikácie alebo autorizácie: Upozornite zodpovedných a pozastavte dotknutú prácu, kým sa neopraví poverenie alebo oprávnenie.
  • Validačné zlyhania: Záznam opravte alebo izolujte namiesto jeho nezmeneného opätovného odoslania.
  • Vyčerpaný povolený objem: Postupujte podľa zdokumentovaného riešenia pre účet namiesto toho, aby ste ho považovali za krátkodobú dopravnú špičku.

Stanovte limit počtu pokusov aj maximálny vek opakovania. Vyčerpané položky presuňte do frontu nedoručiteľných správ s uvedením dôvodu, vlastníka a postupu opätovného spracovania. V opačnom prípade môžu staré zlyhania potichu spotrebovať kapacitu určenú pre nové zásielky.

Škálujte príjem webhookov nezávisle

Ak poskytovateľ ponúka vhodné webhooky, môžu znížiť opakované dotazovanie na stav. Vytvárajú však aj samostatné prichádzajúce pracovné zaťaženie, ktoré musí zostať dostupné počas náporov aktualizácií.

Prijímací koncový bod udržiavajte zameraný: overte požiadavku pomocou zdokumentovaného mechanizmu poskytovateľa, trvalo uložte udalosť a vráťte požadované potvrdenie. Zmeny objednávok, analytiku a správy zákazníkom spracúvajte asynchrónne. Ak by hrozila strata udalosti, nepotvrdzujte jej prijatie pred trvalým prijatím.

Navrhnite konzumentov tak, aby tolerovali duplicitné doručenie, pokiaľ zmluva s poskytovateľom výslovne neurčuje inak. Pri deduplikácii uprednostnite zdokumentovaný stabilný identifikátor udalosti. Ak neexistuje, kompozitnú identitu navrhnite a otestujte starostlivo: použitie samotného označenia stavu by mohlo zlúčiť odlišné udalosti do jednej.

Chráňte sa aj pred aktualizáciami doručenými mimo poradia. Históriu udalostí ukladajte oddelene od odvodeného aktuálneho stavu zásielky. Ak sú k dispozícii, používajte zdokumentované časové pečiatky udalostí a pravidlá prechodov; nepredpokladajte, že poradie doručenia je poradím udalostí alebo že stavy zásielky tvoria univerzálne rastúcu postupnosť.

Zosúladenie udržiavajte cielené a obmedzené rýchlosťou. Môže skúmať podozrivé medzery v doručení alebo nejednoznačné registrácie, no agresívne dotazovanie každej zásielky môže znovu vytvoriť odchádzajúce zaťaženie, ktorému sa webhooky mali vyhnúť.

Testujte obnovu, nielen maximálnu priepustnosť

Testy zaťaženia vlastných komponentov vykonávajte pomocou simulátora poskytovateľa. Testy odosielajúce významnú prevádzku na živého poskytovateľa koordinujte a zostaňte v rámci autorizovaných limitov. Úspešný test by mal preukázať, že systém sa po narušení vráti do normálneho stavu, nielen že prijme veľký nápor.

  • Prehrajte nápor v štýle skladu, po ktorom nasleduje pokračujúca bežná prevádzka.
  • Vložte odpovede s obmedzovaním, zvýšenú latenciu a dočasné zlyhania servera.
  • Simulujte čiastočné odmietnutie dávky a timeout po prijatí na strane servera.
  • Doručte duplicitné webhookové udalosti a udalosti mimo poradia.
  • Prerušte prístup k databáze a overte, že neprijaté udalosti nie sú falošne potvrdené.
  • Spustite spätné doplnenie údajov súbežne so živými registráciami a skontrolujte spravodlivosť.
  • Prehrajte položky z frontu nedoručiteľných správ bez obídenia rýchlostných kontrol.

Sledujte vek najstaršej oprávnenej registrácie, latenciu prijatia, mieru úspešnosti na úrovni záznamov, frekvenciu obmedzovania, objem opakovaní, oneskorenie spracovania webhookov a rast frontu nedoručiteľných správ. Samotná hĺbka frontu nestačí: veľký front sa môže rýchlo vyprázdniť, zatiaľ čo malý front môže obsahovať niekoľko opakovane zlyhávajúcich, obchodne kritických zásielok.

Pred sezónnou špičkou určte prevádzkovú zodpovednosť. Technické oddelenie by malo vlastniť riadenie odosielania a nástroje obnovy; vlastník integrácie by mal potvrdiť oprávnenia u poskytovateľa; prevádzka by mala určiť, ktoré zásielky majú prioritu. Zdokumentujte, kedy pozastaviť importy, požiadať o dodatočnú kapacitu alebo skúmať chýbajúce aktualizácie. Najlepší návrh je taký, ktorý zostáva predvídateľný, keď prevádzka prekročí jeho okamžitú kapacitu spracovania.

Často kladené otázky

Zvýši pridanie API kľúčov priepustnosť?

Nie nevyhnutne. Viaceré kľúče môžu zdieľať limit na úrovni účtu. Rozsah limitu a povolený spôsob škálovania si overte u poskytovateľa. Nepoužívajte rotáciu kľúčov na obchádzanie obmedzení.

Mala by každá registrácia používať najväčšiu možnú dávku?

Nie. Väčšie dávky môžu zlepšiť efektivitu požiadaviek, no čakanie na ich naplnenie zvyšuje latenciu pri nízkom objeme. Použite zdokumentovaný limit veľkosti spolu s časovačom vyprázdnenia a potom nastavenie dolaďte podľa nameranej latencie prijatia a správania pri zlyhaniach.

Ako zabrániť duplicitným registráciám po timeoute?

Použite trvalú lokálnu identitu zásielky a zdokumentované správanie poskytovateľa týkajúce sa idempotencie alebo spracovania duplicít. Ak výsledok zostáva neistý, pred opätovným odoslaním ho podľa možností zosúlaďte. Lokálna deduplikácia sama osebe nedokáže preukázať, či vzdialená požiadavka uspela.

Znamená úspešná registrácia, že informácie o sledovaní sú aktuálne?

Nie. Prijatie registrácie, dostupnosť udalosti dopravcu, spracovanie poskytovateľom a vaše vlastné spracovanie aktualizácie sú samostatné fázy. Merajte ich oddelene, aby sa oneskorený sken dopravcu nezamieňal s backlogom registrácie.

Kedy by mal tím požiadať poskytovateľa o väčšiu kapacitu?

Požiadajte o ňu vtedy, keď predpokladané príchody a požadovaný čas obnovy prekračujú overenú využiteľnú kapacitu po odstránení zbytočných opakovaní, duplicitných odoslaní a neefektívneho dávkovania. Väčší povolený objem neopraví zablokovaného konzumenta ani úzke hrdlo v databáze, preto najprv identifikujte rozhodujúce obmedzenie.

Zdroje

Loading