A Stripe emlékszik a kérésre, amikor a válasz eltűnik

Amit ez a videó tartalmaz

• Az idempotencia egy művelet megismétlésének szándékolt hatásával foglalkozik. A Stripe API v1 egy dokumentált, mentett válasz visszajátszási szerződést is hozzáad.
• Ugyanazon logikai művelet újbóli próbálkozása ugyanazt a kulcsot és paramétereket használja. A műveleti kulcsot külön SDK hívások vagy alkalmazás újraindítások között is meg kell őrizni; egy valóban új művelethez saját kulcsra van szükség.
• Miután a végpont végrehajtása megkezdődik, a Stripe API v1 elmenti az első kérés állapotát és törzsét, beleértve az 500-as hibákat is, és ezt a mentett választ adja vissza az újrapróbálkozásokkor.
• A megváltozott paraméterek ugyanazzal a kulccsal eltérést okoznak. Az érvényesítési hibák és a párhuzamos végrehajtási konfliktusok nem mentenek idempotens eredményt az adott próbálkozáshoz, és újrapróbálhatók.
• A Stripe legalább 24 órán át megőrzi az API v1 kulcsokat, majd ezután törölheti őket. Az unresolved hálózati újrapróbálkozásokat korlátozza az első 24 órára, majd állítsa le és egyeztesse az eredményt a művelet megismétlése előtt.
• Egy gyorsítótárazott 500-as hiba továbbra is lejátszódhat a kapcsolat helyreállítása után. Az eredeti műveletnek lehetnek mellékhatásai; használja a releváns objektumot, a Dashboard kérést és a webhookokat az eredmény megállapításához.
• Az API v2 eltérő visszajátszási szemantikát használ. Egy kulcs nem biztosít univerzális, pontosan egyszeri kézbesítést az e-mailek, a készlet és minden helyi adatbázis-művelet számára.

Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

Egy időtúllépés megszakította a fizetését?

0:00 Azt hiszed, az időtúllépés azt jelenti, hogy a fizetésed sikertelen. A szerver befejezheti, miközben a válasz eltűnik, magabiztosan semmit nem mutatva a fizetési felületen. Miért számíthat fel újra egy újrapróbálkozás? Hogyan emlékszik a Stripe egy próbálkozásra? Mikor kell abbahagynia az újrapróbálkozást? És tartson észben egy csúnya részletet. Egy megjegyzett hiba túlélheti a hálózati problémát.

0:17 Visszatérünk erre. Ez a The Daily Diff, a kulisszák mögött.

Mit azonosít az idempotencia kulcs?

0:21 Az idempotencia azt jelenti, hogy egy művelet ismétlésének ugyanaz a szándékolt hatása, mint egyszeri elvégzésének. Az idempotencia kulcs egy logikai műveletet címkéz. A Stripe API első verziója felismeri ezt a címkét az újrapróbálkozásokkor, és visszajátssza a mentett választ. Képzelj el, hogy kávét vásárolsz. A Stripe befejezi a fizetési kérésedet, és a válasz elveszik, miközben hazafelé tart. A vásárló egy pörgettyűt lát. Lehet, hogy a bankjuknak izgalmasabb értelmezése van. Egy védtelen létrehozási kérés megismételheti a mellékhatást.

Hogyan teszi biztonságossá az újrapróbálkozást ugyanaz a kulcs?

0:45 Csatoljon egy egyedi kulcsot az első próbálkozás előtt, és tartsa meg az újrapróbálkozásokhoz. Ha az alkalmazás újraindul, őrizze meg ezt a kulcsot a művelettel együtt a jegyzékében. A Stripe első verziójú API-ja esetén, amint a végpont végrehajtása megkezdődik, az első kérés állapota és törzse mentésre kerül. Küldje el újra ugyanazt a kulcsot és paramétereket, és a Stripe visszaadja a mentett választ. A kávé a helyén marad, miközben a nyugta ismét útnak indul.

Mit ment pontosan a Stripe?

1:07 Itt van a Stripe tényleges megfogalmazása. Az azonos kulccsal történő újrapróbálkozások a mentett választ adják vissza, beleértve az ötszázas hibákat is. A dokumentáció több munkát végez, mint az Ön optimistán elnevezett újrapróbálkozási segítője. A vásárló újra koppint. Az alkalmazása dönti el, hogy ez folytatja-e a függőben lévő vásárlást, vagy újat kezd. Egy valóban új kávé új kulcsot kap. Minden hálózati újrapróbálkozáshoz új kulcsot használni meghiúsítja a védelmet.

1:27 Különböző paraméterek ugyanazzal a kulccsal eltérést váltanak ki.

Mi történik, ha a kérés megváltozik?

1:30 Ha a paraméterek érvényesítése sikertelen, vagy egy másik, azzal a kulccsal ellátott kérés még mindig végrehajtás alatt áll, a Stripe nem ment idempotens eredményt az adott próbálkozáshoz. Ezek a kérések újrapróbálhatók. Egy versengő kérés konfliktust kap. Ezek az első verzió szabályai. A kettes verzió másképp viselkedik. Egy fejléc nem ígérheti a pontosan egyszeri kézbesítést a rendszerén keresztül. Az e-mail, a készlet és az adatbázis mindegyikének hibakezelésre van szüksége.

1:52 A kulcs védi a műveletet a dokumentált hatókörén belül. A Stripe legalább huszonnégy órán át megőrzi az első verziójú kulcsokat, és utána

Meddig biztonságos újrapróbálkozni a megjegyzett eredménnyel?

1:59 törölheti őket. Egy törölt kulcs új kérést hajthat végre. Tartsa a megoldatlan újrapróbálkozásokat az első napon belül. Ezen túlmenően állítsa le és egyeztesse az eredeti eredményt. Használjon exponenciális visszalépést és jittert, hogy a szervernek legyen ideje. Különben az újrapróbálkozások sorban állnak egy égő kávézó előtt. A Stripe könyvtárai kezelik az újrapróbálkozásokat, de ellenőrizze a könyvtár alapértelmezett beállításait. Az a ragadós hiba a buktató.

Miért jöhet vissza egy megjegyzett hiba újra és újra?

2:20 Egy gyorsítótárazott ötszázas válasz tovább játszódik a kapcsolat helyreállítása után. Az eredeti művelet mellékhatásokat produkálhatott. Oldja meg az eredményt objektumok, a Dashboard és webhookok segítségével. Egy új kulcs megismételheti a műveletet. Ha inkább elolvasná ezt, mint hallaná tőlem, a diff minden reggel megérkezik a beérkező levelei közé, ingyenesen a the daily diff dot dev oldalon, link alább.

Élesíteném-e egy újrapróbálkozás gombot ezzel a szerződéssel?

2:39 Ítélet, a motorháztető alatt. SHIP IT. Én stabil kulcsokat szállítanék korlátozott újrapróbálkozásokkal és egyeztetéssel, hogy az ügyfelek kávét kapjanak anélkül, hogy finanszíroznák a disztribuált rendszerekkel kapcsolatos oktatását. És ennyi a mai diff. Én Niko vagyok az Axrisi-tól. Összevonás felelősségteljesen.

Források

1. Idempotent requestsStripe Docs
2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
3. Advanced error handlingStripe Docs
4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor