Események sorrendje vs. főkönyvi könyvelés

A hálózatok a visszahívásokat nem sorrendben kézbesítik. Egy késői DLR, korai MO vagy egy elszámolás előtti státuszváltás nem hozhat létre második terhelést, és nem írhat át egy már lezárt sort. Ez az oldal a könyvelési sorrend szerződése: a főkönyvi szabályok túlélik az átrendezést — ez nem egy korrelációs azonosító gyorstalpaló és nem egy MO és MT közötti számlázási esszé.

Az érkezési sorrend nem főkönyvi törvény

A HTTP-érkezés csupán szállítási véletlen. A pénz a zárolás → elszámolás → eredményfrissítés útvonalon könyvelődik — nem pedig azon a címszón, hogy «melyik visszahívás futott be utoljára». A USD 1,000/hó szintű puha érték pénzügyi incidensként kezeli az átrendezést, ha a termék sikerességet mutat, miközben a főkönyv kétszer mozgatja az összeget. A USD 20 bizonyítja, hogy egy kényszerített késői DLR soha nem nyit párhuzamos terhelést.

Hogy néz ki a nem sorrendhelyes működés

Könyvelési szabályok, amelyek túlélik az átrendezést

Állítson be zárolást és idempotencia-kulcsokat a mellékhatások előtt (Webhook szerződés az első küldés előtt). Számoljon el egyszer számlázási szándékonként; a későbbi események csak az eredményt frissítik. Soha ne nyisson párhuzamos terhelést a korai vagy késői DLR illetve MO esetén. Utasítsa el vagy parkoltassa az aláírt ablakon kívül — nincs kitalált siker. Exportálja az összekapcsolásokat szándék szerint — nem érkezési idő szerint.

A késés normális, a dupla pénz nem

A hálózati késés elosztott rendszerekben normális. Az, hogy egy szándékért kétszer terhelnek pénzt, a könyvelési logika kudarca. Ha a rendszere ismétlődő terhelést hoz létre egy késői DLR-ből, akkor hibás pénzügyi eseményt kezel. Az egyeztetésnek a szándékazonosítón kell alapulnia, nem a HTTP-érkezési sorrenden. Ne hagyja, hogy a hálózati késés határozza meg a pénzügyi státuszát.

Vásárlói ellenőrzőlista az eseménysorrend és a könyvelés összehasonlításához

Ellenőrizze, hogy rendszere különbséget tesz-e az 'esemény érkezése' és az 'elszámolás' között. Erősítse meg, hogy az idempotencia-kulcs az első küldés előtt létrejön. Ellenőrizze, hogy a késői DLR nem indít-e új terhelést. Győződjön meg arról, hogy a státuszváltás (pl. sikertelenről sikeresre) az eredeti sort frissíti, nem pedig újat hoz létre. Győződjön meg arról, hogy az egyeztetés a szándékazonosítót használja elsődleges forrásként.

Kezdés az IOSOR rendszerrel

Könyvelje a prepaid terhelést az üzleti kulcsra, ne a webhook érkezési sorrendjére. A késő DLR és a korai accepted bármely sorrendben landolhat; a nyilvántartás akkor is egy sort ír. Az aláírási ablakbeli ismétlés nem hozhat létre második terhelést. Kényszerítsen egy késő és egy korai állapotot egy kifizetett küldésen, és bizonyítson egy könyvelést.

Kapcsolódó: A duplikált webhook nem hozhat létre második terhelést · Aláírás és újrajátszási ablak kapu.

IOSOR összegzés

Az érkezési sorrend nem nyilvántartási törvény. A könyvelési kulcs birtokolja a pénzt; a sorsorrend nem.

Tegye: könyveljen egyszer az idempotencia kulcson; a késő DLR állapot, nem új terhelés.

Ne tegye: újra terhelni, mert a DLR jött először, vagy második sort hagyni az ismételt webhooknak.