Podvojeni naročila pri delu z API-jem: vzroki in zaščita

Zakaj se podvojitve pojavijo po enem samem dejanju

Lastnik nadzorne plošče lahko klikne gumb enkrat in vidi več enakih naročil: za sledilce, oglede, odzive ali drugo storitev. Običajno težava ni v samem kliku, ampak v verigi med odjemalcem, API-jem, bazo podatkov in ponudnikom.

S stališča strežnika »en zahtevek« ni vedno en sam. Odjemalec morda ni prejel odgovora in je pošiljanje ponovil, prva operacija pa se je že shranila. Včasih se naročilo v bazi nadzorne plošče ustvari enkrat, a se dvakrat pošlje ponudniku. To so različni scenariji in odpravljajo se na različne načine.

Časovna omejitev ne pomeni, da naročilo ni bilo ustvarjeno

Najpogostejši vzrok je, da odjemalec čaka na odgovor omejen čas. Strežnik sprejme zahtevek, ustvari naročilo, a odgovori pozneje, kot je določena časovna omejitev. Odjemalec meni, da operacija ni uspela, in jo pošlje znova.

Posledično je prvo naročilo že v bazi, drugi zahtevek pa ustvari še eno. To se še posebej pogosto zgodi pri počasnem odgovoru zunanjega API-ja, preobremenjeni čakalni vrsti ali nestabilni povezavi med storitvami.

Časovna omejitev govori le o odsotnosti odgovora, ne pa o odsotnosti obdelave zahtevka.

Samodejna ponovitve na strani odjemalca

Knjižnice za HTTP-zahtevke, opravila v ozadju in integracijske storitve pogosto samodejno ponovijo zahtevek. Povod je lahko napaka pri povezavi, koda odgovora strežnika, prekinitev omrežja ali predolg odgovor.

Ponovitev je sama po sebi koristna: zmanjšuje število izgubljenih naročil ob začasnih motnjah. Pomanjkljivost tega pristopa je, da brez zaščite pred ponovno obdelavo vsako nestabilnost omrežja spremeni v podvojitve.

• ponovitev se lahko sproži v kodi spletnega mesta ali bota;
• opravilo lahko znova zažene čakalna vrsta;
• zahtevek lahko ponovi posrednik ali integracijski modul;
• operater lahko ročno znova pošlje naročilo po napaki.

Ponovni zahtevek prispe pred prvim odgovorom

Včasih dva enaka zahtevka res prideta do API-ja skoraj hkrati. Na primer, uporabnik je dvakrat poslal obrazec, spletni vmesnik ni zaklenil gumba ali pa se je opravilo v ozadju znova zagnalo, preden se je prvo končalo.

Če obdelovalnik najprej preveri obstoj naročila in ga nato ustvari, lahko dve vzporedni operaciji preverjanje opravita hkrati. Vsaka ugotovi, da naročila še ni, in vsaka doda novo zapis.

Takšno situacijo imenujemo tekmovanje podatkov. Preprosto predhodno preverjanje v kodi pred tem ne ščiti v celoti. Pomanjkljivost preverjanja brez omejitve na ravni baze je, da se ob vzporedni obremenitvi zlomi.

Naročilo se je zapisalo, a odgovor API-ja se je izgubil

Zahtevek gre skozi več stopenj: strežnik prejme podatke, ustvari zapis, doda opravilo v čakalno vrsto, pošlje odgovor. Napaka je mogoča med katero koli od njih. Na primer, baza je že potrdila ustvarjanje naročila, a se je povezava prekinila, preden je bil odgovor poslan odjemalcu.

Odjemalec ne ve, ali je bilo naročilo sprejeto, in operacijo ponovi. API brez ločenega mehanizma preverjanja zahtevek obravnava kot novega. V dnevniku je to pogosto videti, kot da je storitev ustvarila dve naročili »sama«, čeprav je prejela dva dohodna klica.

Idempotentni ključ za ustvarjanje naročila

Za operacije ustvarjanja je potreben edinstven ključ idempotentnosti. Odjemalec ga ustvari pred prvim pošiljanjem in ga posreduje skupaj s parametri naročila. Pri ponovitvi zaradi časovne omejitve ali napake se uporabi isti ključ.

API shrani ključ skupaj z rezultatom obdelave. Če prispe zahtevek z že znanim ključem, strežnik ne ustvari novega naročila, ampak vrne rezultat prvega klica: identifikator naročila, njegov status ali prej oblikovano napako.

En ključ mora ustrezati eni poslovni operaciji, ne pa eni HTTP-povezavi.

Pomanjkljivost metode je, da je treba ključe hraniti, jih po pravilih čistiti in preverjati na strani API-ja. Če se ob vsaki ponovitvi ustvari nov ključ, zaščita ne bo delovala. Če se en ključ uporabi za različna naročila, bo del novih operacij pomotoma zavrnjenih.

Edinstvenost mora nadzorovati baza podatkov

Idempotentnost je najbolje dopolniti z omejitvijo edinstvenosti v bazi. Za to se izbere kombinacija, ki nedvoumno opisuje naročilo: notranji identifikator odjemalca, ključ idempotentnosti, vrsta storitve in druga potrebna polja.

Baza podatkov mora zavrniti drugi zapis, tudi če sta dva obdelovalnika do ustvarjanja prišla hkrati. Po konfliktu API vrne obstoječe naročilo, ne pa napake brez pojasnila.

Pomanjkljivost stroge omejitve edinstvenosti je, da je ni mogoče graditi samo na povezavi ali uporabniškem imenu. Odjemalec lahko zavestno naroči eno storitev za isti kanal večkrat. Preširoka omejitev bi blokirala običajne ponovne nakupe.

Čakalna vrsta lahko opravilo dostavi več kot enkrat

Čakalne vrste opravil pogosto delujejo po načelu »dostava vsaj enkrat«. Če je delovni proces opravilo obdelal, a ni uspel potrditi njegove izvedbe, lahko čakalna vrsta isto opravilo znova izroči drugemu delovnemu procesu.

Za čakalno vrsto je to običajen način, da se opravilo ne izgubi. Za ustvarjanje naročila brez idempotentnosti pa je to vir podvojitev. Identifikator opravila ali ločen ključ operacije je treba posredovati do končnega obdelovalnika, vključno z modulom za pošiljanje naročila ponudniku.

Pomanjkljivost izklopa ponovne dostave je, da lahko ob padcu delovnega procesa del naročil izgine. Varneje je sprejemati možne ponovitve in obdelovalnik narediti odporen nanje.

Podvojitve nastanejo med nadzorno ploščo in ponudnikom

Notranje naročilo je lahko ustvarjeno enkrat, a je zahtevek do zunanjega API-ja poslan dvakrat. Vzrok je isti: nadzorna plošča ni prejela odgovora ponudnika in se je odločila pošiljanje ponoviti. Če je ponudnik prvi zahtevek že sprejel, bosta na njegovi strani dve enaki prijavi.

Potrebna je ločena povezava notranjega naročila z zunanjim: identifikator pošiljanja, ključ idempotentnosti ali shranjen odgovor ponudnika. Ne smemo domnevati, da bo zaščita na vhodu v lastno nadzorno ploščo samodejno zaščitila odhodne klice.

Pomanjkljivost usklajevanja z zunanjim API-jem je, da vsak ponudnik ne podpira iskanja po zunanjem ključu. Takrat je treba beležiti poskuse pošiljanja in ločeno obravnavati nedoločene statuse.

Spletni kavelj ne sme ustvariti novega naročila

Spletni kavlji sporočajo spremembe: naročilo je sprejeto, zagnano, izvedeno, preklicano ali zahteva preverjanje. Napaka nastane, ko obdelovalnik spletnega kavlja obvestilo razume kot ukaz za ponovno ustvarjanje naročila.

Isti spletni kavelj lahko prispe večkrat. Pošiljatelj ponovi dostavo, če ni prejel potrditve, obvestila pa včasih prispejo tudi ne po vrstnem redu. Obdelovalnik mora najti obstoječe naročilo po zunanjem identifikatorju in posodobiti status.

Pomanjkljivost obdelave spletnih kavljev samo po času prejema je, da lahko poznejše obvestilo prepiše aktualni status s zastarelim. Potrebni so identifikator dogodka, različica statusa ali jasna pravila prehodov.

Kateri zapisi pomagajo najti vir podvojitev

Za preiskavo ni dovolj videti le dve številki naročil. Potrebni so podatki o vsaki stopnji obdelave: čas zahtevka, ključ idempotentnosti, identifikator odjemalca, parametri naročila, številka opravila v ozadju, odgovor zunanjega API-ja in poskusi ponovnega pošiljanja.

• podvojitve primerjajte po ključu operacije, ne le po povezavi;
• preverite, ali so bili enaki zahtevki v dnevniku dohodnega API-ja;
• poglejte, ali se je opravilo v čakalni vrsti ponovilo;
• ločite ustvarjanje notranjega naročila od pošiljanja ponudniku;
• shranite zunanji identifikator prijave takoj po prejemu odgovora.

Pomanjkljivost prekratkih dnevnikov je, da vir težave izgine, preden ga uspejo razčleniti. Pomanjkljivost pretiranega beleženja je, da lahko v zapis zaidejo žetoni, osebni podatki in druga občutljiva polja, zato jih je treba maskirati.

Kako obravnavati nedoločen rezultat zahtevka

Po časovni omejitvi ni dovoljeno takoj znova ustvariti naročila z novimi podatki. Najprej mora API preveriti operacijo po ključu idempotentnosti ali identifikatorju odjemalca. Če je naročilo najdeno, se vrne njegovo trenutno stanje. Če obdelava še poteka, odjemalec prejme status čakanja.

1. Ustvarite ključ operacije pred prvim zahtevkom.
2. Pošiljajte isti ključ ob vsaki ponovitvi.
3. Shranite ključ in naročilo v eni zaščiteni operaciji baze podatkov.
4. Posredujte identifikator operacije v čakalno vrsto in zunanji API.
5. Ob ponovnem klicu vrnite prej ustvarjeno naročilo.

Tak scenarij zahteva nadgradnjo API-ja in integracije na strani odjemalca. Njegova pomanjkljivost je zahtevnejše odpravljanje napak in več stanj naročila, a ponovna dostava zahtevka preneha samodejno pomeniti ponovni nakup.