„Tracking API“ mastelio keitimas: kaip valdyti piko sezono apimtį, užklausų dažnio ribojimus ir masinę registraciją

Norėdami padidinti sekimo API našumą piko sezono metu, siuntų registravimą nukreipkite per patikimą eilę, užtikrinkite teikėjo limitų laikymąsi visuose darbuotojuose, grupuokite užklausas tik neviršydami dokumentacijoje nurodytų ribų ir sekimo atnaujinimus apdorokite asinchroniškai. Registravimo pralaidumą, pakartotinių bandymų srautą ir webhook apdorojimą vertinkite kaip atskiras pajėgumo problemas. Pridėjus daugiau darbuotojų, bet nekontroliuojant siunčiamų užklausų, ribojimas gali sustiprėti, o ne sumažėti laukiančių užduočių eilė.

Inžinerijos komandoms, jungiančioms užsakymų valdymo sistemą, sandėlio platformą ar el. prekybos infrastruktūrą prie sekimo paslaugos, tikslas nėra tiesiog siųsti daugiau užklausų. Reikia per nustatytą laiką užregistruoti siuntas, išsaugoti atnaujinimus staiga išaugus srautui ir atkurti veikimą po gedimų nesukuriant pasikartojančio darbo.

Įvertinkite darbo krūvį pagal siuntas, užklausas ir atnaujinimus

Kasdienis siuntų kiekis nėra pakankamas integracijos pajėgumui nustatyti. Sandėlis gali išleisti didžiąją dalį sekimo numerių per trumpą išsiuntimo laikotarpį, o būsenos atnaujinimai gali ateiti visą dieną. Šiuos darbo krūvius modeliuokite atskirai.

• Registravimo srautas: nauji siuntų įrašai, patenkantys į jūsų sistemą per sekundę ar minutę, įskaitant importus ir siuntų išleidimo iš sandėlio šuolius.
• Išeinantis API srautas: registravimo užklausos, paieškos, pataisymai, sutikrinimo užklausos ir pakartotiniai bandymai.
• Įeinantis atnaujinimų srautas: webhook pristatymai ir pakartotiniai pristatymai, jei teikėjas juos palaiko.
• Tolesnis apdorojimas: duomenų bazės įrašai, klientų pranešimai, analitikos įvykiai ir užsakymo būsenos pakeitimai, suaktyvinami kiekvieno atnaujinimo.

Nustatykite vidinį registravimo tikslą, pavyzdžiui, didžiausią priimtiną laiką nuo sekimo numerio gavimo iki registravimo patvirtinimo. Atskirai vertinkite sekimo informacijos atnaujinimo savalaikiškumą: sėkmingas registravimas nereiškia, kad vežėjo skenavimo informacija jau prieinama.

Apskaičiuokite faktinį registravimo pajėgumą

Užklausomis ribojamam registravimo galiniam taškui naudinga planavimo sąsaja yra:

Registravimo pajėgumas = leidžiamos užklausos per sekundę × vidutinis įrašų skaičius užklausoje × sėkmingų įrašų dalis

Tai yra planavimo įvertis, o ne teikėjo garantija. Daroma prielaida, kad lemiamas apribojimas yra užklausų limitas. Įrašais pagrįstos kvotos, naudingojo turinio dydis, delsa ir bendri paskyros limitai gali nustatyti mažesnę viršutinę ribą.

Tik iliustracijai tarkime, kad integracijai leidžiama siųsti dvi registravimo užklausas per sekundę, o kiekvienoje užklausoje vidutiniškai siunčiama po 30 įrašų. Nominalus pajėgumas prieš gedimus ir kitus apribojimus yra 60 įrašų per sekundę. Jei nuolatinio srauto metu gaunama vidutiniškai 80 įrašų per sekundę, eilė didėja maždaug 20 įrašų per sekundę. Šie skaičiai yra hipotetiniai, jie nėra 17TRACK limitai.

Taip pat apskaičiuokite atkūrimo pajėgumą. Jei nauji įrašai ir toliau gaunami greičiu λ, o faktinis apdorojimo pajėgumas yra μ, esamai B įrašų eilei ištuštinti prireiks maždaug B / (μ − λ) sekundžių, kai μ > λ. Jei apdorojimo pajėgumas neviršija gaunamo srauto, tokiomis sąlygomis eilė neištuštės.

Patvirtinkite, ką iš tikrųjų riboja teikėjas

Greičio limitas ir naudojimo leidimas sprendžia skirtingas problemas. Greičio limitas kontroliuoja, kaip greitai galima pateikti užklausas ar įrašus. Naudojimo leidimas gali kontroliuoti, kiek sekimo veiklos paskyra gali sunaudoti per atsiskaitymo ar suteiktų teisių laikotarpį. Neviršijant vieno limito, neatitikimas kitam nėra užtikrinamas.

Prieš nustatydami darbuotojų skaičių, pagal teikėjo dokumentaciją ir paskyros sąlygas patvirtinkite:

• Ar limitai taikomi paskyrai, API raktui, galiniam taškui, IP adresui ar kitai sričiai.
• Ar skaičiuojamas vienetas yra užklausa, sekimo įrašas ar kita operacija.
• Ar galiniai taškai dalijasi limitu, ar turi atskirus leidimus.
• Koks didžiausias vienoje užklausoje leidžiamų įrašų ir naudingojo turinio dydis.
• Kaip naudojimą veikia pasikartojantys pateikimai, negaliojantys įrašai ir pakartotiniai bandymai.
• Ar atsakymai pateikia ribojimo informaciją arba rekomendacijas dėl pakartotinio bandymo.
• Kuo kvotos išnaudojimas skiriasi nuo laikino ribojimo.

17TRACK integracijai pradėkite nuo oficialaus Tracking API puslapio ir API dokumentacijos. Prieš diegdami patvirtinkite taikomo galinio taško veikimą ir paskyros limitus. Šiame vadove pateikti pajėgumo pavyzdžiai yra architektūros iliustracijos, o ne teiginiai apie 17TRACK suteiktas teises, paketų dydžius ar paslaugos garantijas.

Tarp užsakymų apdorojimo ir registravimo įterpkite patikimą eilę

Neverskite atsiskaitymo proceso ar sandėlio užbaigimo laukti, kol sekimo teikėjas priims registraciją. Išsaugokite siuntą vietoje, patikimai įrašykite registravimo užduotį ir perduokite pateikimą foniniams darbuotojams.

Praktinis srautas:

1. Išsaugokite siuntą ir jos registravimo ketinimą. Naudokite transakcinį outbox arba lygiavertį projektą, kad išsaugant užsakymą nebūtų prarasta foninė užduotis.
2. Patikrinkite ir normalizuokite įvestis. Sekimo numerius saugokite kaip eilutes, įskaitant pradinius nulius. Vežėjui būdingą normalizavimą taikykite tik tada, kai jis pagrįstas.
3. Patikrinkite, ar registracija jau egzistuoja. Naudokite stabilų identifikatorių, tinkamą teikėjui ir jūsų duomenų modeliui.
4. Į eilę įtraukite tinkamus įrašus. Išsaugokite bandymų skaičių, kitą tinkamo pakartotinio bandymo laiką ir pakankamai konteksto diagnozei.
5. Pateikite per bendrą ribotuvą. Pajėgumą rezervuokite prieš pat siunčiamą užklausą.
6. Išsaugokite įrašo lygio rezultatus. Atskirai žymėkite patvirtintą sėkmę, pakartotinai bandomą nesėkmę, galutinį atmetimą ir neaiškius rezultatus.

Eilė sugeria srauto šuolį, bet nesukuria teikėjo pajėgumo. Jei seniausias tinkamas įrašas nuolat sensta, nagrinėkite skirtumą tarp gaunamo srauto ir apdorojimo pajėgumo, o ne tiesiog didinkite darbuotojų skaičių.

Koordinuokite limitus visuose darbuotojuose

Nepriklausomi darbuotojai neturi manyti, kad kiekvienas gali išnaudoti visą paskyrai suteiktą leidimą. Naudokite koordinuojamą greičio ribotuvą arba dispečerį, paskirstantį bendrą užklausų biudžetą. Į šį biudžetą įtraukite suplanuotus importus, operacinius scenarijus ir sutikrinimo užduotis.

Greičio limitas ir lygiagretumas yra skirtingi valdikliai. Ribotuvas kontroliuoja, kaip dažnai pradedamos užklausos, o lygiagretumo riba kontroliuoja, kiek jų lieka vykdoma. Abu naudingi, kai didėja teikėjo delsa. Padidinus lygiagretumą gali pagerėti delsos ribojamas darbo krūvis, tačiau tai nepanaikins siunčiamų užklausų greičio limito.

Naudokite grupinį registravimą neprarasdami įrašo lygio kontrolės

Jei galinis taškas palaiko kelis įrašus vienoje užklausoje, grupavimas gali sumažinti užklausų sąnaudas. Tačiau jis nebūtinai sumažina įrašais pagrįstą naudojimą, o didžiausias leidžiamas paketo dydis ne visada yra geriausias operacinis pasirinkimas.

Paketus formuokite pagal du kriterijus: didžiausią įrašų skaičių ir didžiausią laukimo laiką. Pateikite paketą, kai pasiekiamas bet kuris iš jų. Taip intensyviais laikotarpiais paketai efektyviai užpildomi, o mažo srauto metu nereikia laukti neribotą laiką.

• Laikykitės ne tik įrašų skaičiaus, bet ir naudingojo turinio limitų. Dėl pasirenkamų metaduomenų vienodo dydžio paketai gali labai skirtis baitais.
• Saugokite vidinį paketo manifestą. Užrašykite, kurie vietiniai siuntų identifikatoriai buvo pateikti, ir tinkamai susiekite kiekvieną grąžintą rezultatą.
• Tikrinkite taikomosios programos lygio rezultatus. Sėkmingas HTTP atsakymas savaime neįrodo, kad buvo priimtas kiekvienas įrašas.
• Pakartotinai siųskite tik tuos įrašus, kuriems to reikia. Sėkmingų įrašų pakartojimas sukuria nereikalingą srautą ir gali turėti įtakos naudojimui.
• Nuolatines validavimo klaidas nukreipkite taisyti. Nepakeistas negaliojantis naudingasis turinys neturi cirkuliuoti pakartotinių bandymų eilėje.

Ypač svarbus yra skirtojo laiko pabaigos atvejis: teikėjas galėjo priimti užklausą, nors jūsų klientas negavo atsakymo. Tokį rezultatą pažymėkite kaip neaiškų. Išspręskite jį naudodami palaikomą idempotentiškumo mechanizmą, dokumentuotą pasikartojančio registravimo taisyklę arba, jei įmanoma, sutikrinimo paiešką. Nemanykite, kad rašymo operacija nepavyko vien todėl, kad baigėsi skirtasis laikas.

Atskirkite tiesioginį srautą nuo istorinių importų

Atgalinis įkėlimas neturi sunaudoti viso pajėgumo, reikalingo naujai išsiųstoms siuntoms. Naudokite atskiras eiles su svertiniu planavimu arba aiškiai rezervuotu pajėgumu. Leiskite importams naudoti laisvą pajėgumą, išlaikydami minimalią dalį tiesioginiams registravimams. Taikykite senėjimo arba kitą sąžiningumo taisyklę, kad žemesnio prioriteto įrašai galiausiai būtų apdoroti.

Pakartotinius bandymus valdykite, atidėkite ir apribokite

HTTP 429 reiškia „Per daug užklausų“. RFC 6585 nurodo, kad 429 atsakyme gali būti Retry-After antraštė. RFC 9110 apibrėžia, kad šios antraštės reikšmė gali būti HTTP data arba delsa sekundėmis. Klientas turi analizuoti abu formatus, o ne manyti, kad visada grąžinamas sveikasis skaičius.

Kai pateikiama galiojanti pakartotinio bandymo delsa, nekartokite bandymo, kol ji nesibaigė. Kai rekomendacijų nėra, naudokite apribotą eksponentinį atsitraukimą su atsitiktiniu svyravimu: palaipsniui didinkite delsą tarp bandymų ir pridėkite atsitiktinumo, kad visi darbuotojai nekartotų bandymo vienu metu. Pakartotiniai bandymai turi eiti per tą patį siunčiamų užklausų ribotuvą kaip ir pirmieji bandymai.

Prieš pakartotinį bandymą klasifikuokite klaidas:

• Ribojimas: atidėkite paveiktą darbą ir sumažinkite siuntimo spaudimą atitinkamo limito srityje.
• Laikini tinklo ar serverio gedimai: pakartokite bandymą pagal ribotą politiką, atsižvelgdami į neaiškius rašymo rezultatus.
• Autentifikavimo ar autorizavimo klaidos: įspėkite ir sustabdykite paveiktą darbą, kol bus pataisyti kredencialai ar leidimai.
• Validavimo klaidos: pataisykite arba izoliuokite įrašą, o ne siųskite jį dar kartą nepakeistą.
• Išnaudotas leidimas: vadovaukitės dokumentuota paskyros problemos sprendimo tvarka, o ne laikykite tai trumpalaikiu srauto šuoliu.

Nustatykite ir bandymų skaičiaus limitą, ir maksimalų pakartotinių bandymų amžių. Išnaudotus elementus perkelkite į neapdorotų pranešimų eilę, nurodydami priežastį, atsakingą asmenį ir pakartotinio paleidimo procedūrą. Priešingu atveju senos klaidos gali nepastebimai sunaudoti pajėgumą, skirtą naujoms siuntoms.

Įeinančių webhook pranešimų priėmimą didinkite nepriklausomai

Jei teikėjas siūlo tinkamus webhook, jie gali sumažinti pakartotinį būsenos tikrinimą. Tačiau jie taip pat sukuria atskirą įeinantį darbo krūvį, kuris turi išlikti prieinamas atnaujinimų šuolių metu.

Priėmimo galinį tašką laikykite koncentruotą: patikrinkite užklausą naudodami teikėjo dokumentuotą mechanizmą, patikimai išsaugokite įvykį ir grąžinkite reikiamą patvirtinimą. Užsakymo pakeitimus, analitiką ir klientų pranešimus apdorokite asinchroniškai. Nepatvirtinkite gavimo prieš patikimą priėmimą, jei dėl to galėtų būti prarastas įvykis.

Konsumentai turi toleruoti pasikartojantį pristatymą, nebent teikėjo sutartyje aiškiai nustatyta kitaip. Dublikatams šalinti pirmenybę teikite dokumentuotam stabiliam įvykio identifikatoriui. Jei jo nėra, kruopščiai suprojektuokite ir išbandykite sudėtinį identifikatorių: naudojant vien būsenos žymą skirtingi įvykiai gali būti klaidingai sujungti į vieną.

Taip pat apsisaugokite nuo ne eilės tvarka gaunamų atnaujinimų. Įvykių istoriją saugokite atskirai nuo išvestinės dabartinės siuntos būsenos. Jei įmanoma, taikykite dokumentuotas įvykių laiko žymas ir perėjimų taisykles; nemanykite, kad gavimo tvarka yra įvykių tvarka arba kad siuntų būsenos visada sudaro didėjančią seką.

Sutikrinimą vykdykite tikslingai ir ribokite jo greitį. Jis gali tirti įtariamus pristatymo trūkius ar neaiškius registravimus, tačiau agresyvus kiekvienos siuntos apklausimas gali atkurti išeinantį srautą, kurio webhook turėjo padėti išvengti.

Tikrinkite atkūrimą, ne tik didžiausią pralaidumą

Apkrovos bandymus vykdykite su savo komponentais naudodami teikėjo simuliatorių. Bandymus, siunčiančius reikšmingą srautą realiam teikėjui, derinkite ir neviršykite leidžiamų limitų. Sėkmingas bandymas turi parodyti, kad sistema po sutrikimo grįžta į normalią būseną, o ne tik kad priima didelį srauto šuolį.

• Pakartokite sandėliui būdingą srauto šuolį, po kurio tęsiasi įprastas srautas.
• Įterpkite ribojimo atsakymus, padidėjusią delsą ir laikinus serverio gedimus.
• Imituokite dalinį paketo atmetimą ir skirtosios trukmės pabaigą po priėmimo serverio pusėje.
• Pristatykite pasikartojančius ir ne eilės tvarka gaunamus webhook įvykius.
• Nutraukite prieigą prie duomenų bazės ir patikrinkite, ar nepriimti įvykiai klaidingai nepatvirtinami.
• Vykdykite atgalinį įkėlimą kartu su tiesioginiais registravimais ir patikrinkite sąžiningumą.
• Pakartotinai paleiskite neapdorotus elementus neapeidami greičio valdiklių.

Stebėkite seniausio tinkamo registravimo amžių, priėmimo delsą, įrašo lygio sėkmės rodiklį, ribojimo dažnį, pakartotinių bandymų kiekį, webhook apdorojimo delsą ir neapdorotų pranešimų eilės augimą. Vien eilės dydžio nepakanka: didelė eilė gali greitai ištuštėti, o mažoje eilėje gali būti keli nuolat žlungantys, verslui kritiškai svarbūs siuntų įrašai.

Prieš piko sezoną paskirkite operacinę atsakomybę. Inžinerija turi būti atsakinga už siuntimo valdiklius ir atkūrimo įrankius; integracijos savininkas turi patvirtinti teikėjo suteiktas teises; operacijos turi nustatyti, kurioms siuntoms teikiamas prioritetas. Dokumentuokite, kada stabdyti importus, prašyti papildomo pajėgumo ar tirti trūkstamus atnaujinimus. Geriausia yra tokia konstrukcija, kuri išlieka nuspėjama, kai srautas viršija tiesioginį apdorojimo pajėgumą.

DUK

Ar pridėjus API raktų padidės pralaidumas?

Nebūtinai. Keli raktai gali dalytis paskyros lygio leidimu. Su teikėju patvirtinkite limito taikymo sritį ir leidžiamą didinimo būdą. Nenaudokite raktų kaitaliojimo apribojimams apeiti.

Ar kiekvienai registracijai reikia naudoti didžiausią įmanomą paketą?

Ne. Didesni paketai gali pagerinti užklausų efektyvumą, tačiau laukimas, kol jie bus užpildyti, mažo srauto metu padidina delsą. Naudokite dokumentuotą dydžio viršutinę ribą ir išsiuntimo laikmatį, tada derinkite pagal išmatuotą priėmimo delsą ir gedimų elgseną.

Kaip išvengti pasikartojančių registravimų pasibaigus skirtajam laikui?

Naudokite patikimą vietinį siuntos identitetą ir teikėjo dokumentuotą idempotentiškumo arba pasikartojančio apdorojimo elgseną. Jei rezultatas lieka neaiškus, prieš pakartotinį pateikimą sutikrinkite jį, jei tai palaikoma. Vien vietinis dublikatų šalinimas negali įrodyti, ar nuotolinė užklausa buvo sėkminga.

Ar sėkmingas registravimas reiškia, kad sekimo informacija yra aktuali?

Ne. Registravimo priėmimas, vežėjo įvykio prieinamumas, teikėjo apdorojimas ir jūsų pačių atnaujinimų apdorojimas yra atskiri etapai. Matuokite juos atskirai, kad uždelstas vežėjo skenavimas nebūtų palaikytas registravimo eilės problema.

Kada komanda turėtų prašyti didesnio teikėjo pajėgumo?

Prašykite jo tada, kai prognozuojamas gaunamas srautas ir reikalingas atkūrimo laikas viršija patikrintą naudojamą pajėgumą, pašalinus išvengiamus pakartotinius bandymus, pasikartojančius pateikimus ir neefektyvų grupavimą. Didesnis leidimas nepašalins užblokuoto vartotojo ar duomenų bazės trikdžio, todėl pirmiausia nustatykite lemiamą apribojimą.

Šaltiniai

• 17TRACK Tracking API — oficialus API pasiūlymo pradžios taškas.
• 17TRACK API documentation — integracijos reikalavimų, galinių taškų veikimo ir taikomų užklausų apribojimų tikrinimo šaltinis.
• RFC 6585, Section 4: 429 Too Many Requests — HTTP ribojimo semantika ir pasirenkamos Retry-After rekomendacijos.
• RFC 9110, Section 10.2.3: Retry-After — HTTP datos ir delsos sekundėmis formatai.
• RFC 9110, Section 9.2.2: Idempotent Methods — pakartotinio bandymo aspektai, kai užklausos rezultatas neaiškus.