Rendelések duplikálódása API használatakor: okok és védelem

Miért jelennek meg duplikátumok egyetlen művelet után

A panel tulajdonosa egyszer kattinthat a gombra, és mégis több azonos rendelést láthat: követőkre, megtekintésekre, reakciókra vagy más szolgáltatásra. A probléma általában nem magában a kattintásban rejlik, hanem az ügyfél, az API, az adatbázis és a szolgáltató közötti láncban.

A szerver szempontjából az „egy kérés” nem mindig egy. Lehet, hogy az ügyfél nem kapott választ, újraküldte a kérést, az első művelet pedig már elmentődött. Néha a rendelés egyszer jön létre a panel adatbázisában, de kétszer megy ki a szolgáltatónak. Ezek különböző forgatókönyvek, és különbözőképpen javíthatók.

Az időtúllépés nem jelenti azt, hogy a rendelés nem jött létre

A leggyakoribb ok, hogy az ügyfél korlátozott ideig vár a válaszra. A szerver fogadja a kérést, létrehozza a rendelést, de a beállított időtúllépésnél később válaszol. Az ügyfél sikertelennek tekinti a műveletet, és újraküldi.

Ennek eredményeként az első rendelés már ott van az adatbázisban, a második kérés pedig létrehoz még egyet. Ez különösen gyakran fordul elő lassú külső API-válasz, túlterhelt sor vagy instabil kapcsolat esetén a szolgáltatások között.

Az időtúllépés csak a válasz hiányát jelzi, nem a kérés feldolgozásának hiányát.

Automatikus ismétlések az ügyfél oldalán

A HTTP-kérésekhez használt könyvtárak, háttérfeladatok és integrációs szolgáltatások gyakran automatikusan ismétlik a kérést. Ennek oka lehet kapcsolódási hiba, szerver válaszkód, hálózatkimaradás vagy túl lassú válasz.

Az ismétlés önmagában hasznos: csökkenti az elveszett rendelések számát átmeneti hibák esetén. Ennek a megközelítésnek a hátránya, hogy az ismételt feldolgozás elleni védelem nélkül a hálózat bármilyen instabilitását duplikátumokká alakítja.

• az ismétlés elindulhat a webhely vagy a bot kódjában;
• a feladatot újraindíthatja a sor;
• a kérést ismételheti egy proxy vagy integrációs modul;
• az operátor manuálisan újraküldheti a rendelést hiba után.

Az ismételt kérés az első válasz előtt érkezik

Néha két azonos kérés valóban szinte egyidejűleg érkezik az API-hoz. Például a felhasználó kétszer küldte el az űrlapot, a frontend nem tiltotta le a gombot, vagy a háttérfeladat az első befejezése előtt újraindult.

Ha a kezelő először ellenőrzi a rendelés meglétét, majd létrehozza azt, két párhuzamos művelet egyszerre mehet át az ellenőrzésen. Mindkettő azt látja, hogy a rendelés még nem létezik, és mindkettő új rekordot ad hozzá.

Ezt a helyzetet adatversenynek nevezik. Az egyszerű előzetes ellenőrzés a kódban nem véd teljesen ellene. Az adatbázis szintű korlátozás nélküli ellenőrzés hátránya, hogy párhuzamos terhelés esetén meghibásodik.

A rendelés rögzítődött, de az API-válasz elveszett

A kérés több szakaszon megy keresztül: a szerver fogadja az adatokat, létrehozza a rekordot, sorba állítja a feladatot, elküldi a választ. Bármelyik között bekövetkezhet hiba. Például az adatbázis már megerősítette a rendelés létrehozását, de a kapcsolat megszakadt, mielőtt a válasz eljutott volna az ügyfélhez.

Az ügyfél nem tudja, hogy a rendelést elfogadták-e, és megismétli a műveletet. Az API külön ellenőrzési mechanizmus nélkül új kérésként értelmezi. A naplóban ez gyakran úgy tűnik, mintha a szolgáltatás „magától” hozott volna létre két rendelést, pedig két bejövő hívása volt.

Idempotens kulcs a rendelés létrehozásához

A létrehozási műveletekhez egyedi idempotenciakulcsra van szükség. Az ügyfél az első küldés előtt generálja, és a rendelés paramétereivel együtt továbbítja. Időtúllépés vagy hiba miatti ismétléskor ugyanazt a kulcsot használja.

Az API a kulcsot a feldolgozás eredményével együtt tárolja. Ha már ismert kulccsal érkezik kérés, a szerver nem hoz létre új rendelést, hanem visszaadja az első hívás eredményét: a rendelés azonosítóját, állapotát vagy a korábban képzett hibát.

Egy kulcsnak egy üzleti művelethez kell tartoznia, nem egy HTTP-kapcsolathoz.

A módszer hátránya, hogy a kulcsokat tárolni kell, szabályok szerint tisztítani és az API oldalán ellenőrizni. Ha minden ismétléskor új kulcsot generálunk, a védelem nem működik. Ha egy kulcsot különböző rendelésekhez használunk, néhány új művelet tévesen elutasításra kerül.

Az egyediséget az adatbázisnak kell ellenőriznie

Az idempotenciát célszerű az adatbázisban lévő egyediségi korlátozással kiegészíteni. Ehhez olyan kombinációt választanak, amely egyértelműen leírja a rendelést: belső ügyfélazonosító, idempotenciakulcs, szolgáltatástípus és más szükséges mezők.

Az adatbázisnak el kell utasítania a második rekordot, még akkor is, ha két kezelő egyszerre jutott el a létrehozáshoz. Ütközés után az API a létező rendelést adja vissza, nem pedig magyarázat nélküli hibát.

A szigorú egyediségi korlátozás hátránya, hogy nem építhető csak hivatkozásra vagy username-re. Az ügyfél szándékosan is rendelhet ugyanarra a csatornára egy szolgáltatást többször. A túl széles korlátozás blokkolja a normális ismételt vásárlásokat.

A sor többször is kézbesítheti a feladatot

A feladatsorok gyakran a „legalább egyszeri kézbesítés” elvén működnek. Ha a worker feldolgozta a feladatot, de nem tudta időben visszaigazolni a végrehajtását, a sor ugyanazt a feladatot újra kiadhatja egy másik workernek.

A sor számára ez a feladat elvesztésének elkerülését szolgáló normál módszer. Az idempotencia nélküli rendeléslétrehozás számára viszont a duplikátumok forrása. A feladatazonosítót vagy egy külön műveletkulcsot el kell juttatni a végső kezelőig, beleértve a rendelés szolgáltatónak történő elküldéséért felelős modult is.

Az ismételt kézbesítés kikapcsolásának hátránya, hogy a worker összeomlása esetén néhány rendelés elveszhet. Biztonságosabb elfogadni a lehetséges ismétléseket, és ellenállóvá tenni a kezelőt velük szemben.

Duplikátumok keletkeznek a panel és a szolgáltató között

A belső rendelés egyszer jöhet létre, de a külső API-hoz intézett kérés kétszer kerül elküldésre. Az ok ugyanaz: a panel nem kapott választ a szolgáltatótól, és úgy döntött, hogy újraküldi. Ha a szolgáltató már fogadta az első kérést, nála két azonos igénylés jelenik meg.

Külön kapcsolatra van szükség a belső rendelés és a külső között: küldési azonosító, idempotenciakulcs vagy a szolgáltató eltárolt válasza. Nem feltételezhető, hogy a saját panel bejáratánál lévő védelem automatikusan védi a kimenő hívásokat.

A harmadik féltől származó API-val való egyeztetés hátránya, hogy nem minden szolgáltató támogatja a külső kulcs szerinti keresést. Ilyenkor rögzíteni kell a küldési kísérleteket, és külön kell kezelni a bizonytalan állapotokat.

A webhook nem hozhat létre új rendelést

A webhookok változásokról értesítenek: a rendelést elfogadták, elindították, teljesítették, törölték vagy ellenőrzést igényel. A hiba akkor keletkezik, amikor a webhook kezelője az értesítést új rendelés létrehozására vonatkozó parancsként értelmezi.

Ugyanaz a webhook ismételten megérkezhet. A küldő megismétli a kézbesítést, ha nem kapott visszaigazolást, és az értesítések néha nem sorrendben érkeznek. A kezelőnek a külső azonosító alapján meg kell találnia a létező rendelést, és frissítenie kell az állapotát.

A webhookok csak a beérkezés ideje szerinti feldolgozásának hátránya, hogy egy késői értesítés felülírhatja az aktuális állapotot egy elavulttal. Eseményazonosítóra, állapotverzióra vagy egyértelmű átmeneti szabályokra van szükség.

Milyen rekordok segítenek megtalálni a duplikátumok forrását

A vizsgálathoz nem elég csak két rendelésszámot látni. Adatokra van szükség a feldolgozás minden szakaszáról: a kérés ideje, idempotenciakulcs, ügyfélazonosító, rendelési paraméterek, háttérfeladat száma, a külső API válasza és az ismételt küldési kísérletek.

• a duplikátumokat a műveletkulcs alapján párosítsa, ne csak a hivatkozás alapján;
• ellenőrizze, voltak-e azonos kérések a bejövő API naplójában;
• nézze meg, ismétlődött-e a feladat a sorban;
• különítse el a belső rendelés létrehozását a szolgáltatónak történő elküldéstől;
• a külső igénylés azonosítóját a válasz kézhezvétele után azonnal mentse el.

A túl rövid naplók hátránya, hogy a probléma forrása eltűnik, mielőtt sikerülne elemezni. A túlzott naplózás hátránya, hogy a rekordba tokenek, személyes adatok és más érzékeny mezők kerülhetnek, ezért ezeket maszkolni kell.

Hogyan kezeljük a kérés bizonytalan eredményét

Időtúllépés után nem szabad azonnal új rendelést létrehozni új adatokkal. Először az API-nak ellenőriznie kell a műveletet az idempotenciakulcs vagy az ügyfélazonosító alapján. Ha a rendelés megtalálható, a jelenlegi állapotát adja vissza. Ha a feldolgozás még folyamatban van, az ügyfél várakozási állapotot kap.

1. Hozzon létre műveletkulcsot az első kérés előtt.
2. Minden ismétléskor ugyanazt a kulcsot küldje.
3. A kulcsot és a rendelést egyetlen védett adatbázis-műveletben mentse el.
4. A művelet azonosítóját adja át a sornak és a külső API-nak.
5. Ismételt hívás esetén a korábban létrehozott rendelést adja vissza.

Ez a forgatókönyv az API és az ügyfélintegráció módosítását igényli. Hátránya, hogy bonyolultabb a hibakeresés és több rendelési állapot van, viszont a kérés ismételt kézbesítése többé nem jelent automatikusan ismételt vásárlást.