Transaktionell inbox
En transaktionell inbox använder beständiga meddelandeposter för att skydda lokal behandling mot dubbla leveranser.
En transaktionell inbox använder beständiga meddelandeposter för att skydda lokal behandling mot dubbla leveranser. I varianten som beskrivs här sparas registreringen av ett behandlat meddelande och ändringen av verksamhetsdata i samma databastransaktion.
En fiktiv tjänst med konsumentnamnet report-worker tar emot meddelandet E-42. Den skriver kombinationen av konsument och meddelande-ID i sin inbox och ökar en rapporträknare från 6 till 7. Båda ändringarna committas tillsammans. Ett unikhetsvillkor i databasen för kombinationen skyddar även när flera instanser arbetar samtidigt. Att först kontrollera och sedan skriva räcker inte i sig.
Tidpunkten för kraschen spelar roll
Om transaktionen misslyckas före commit består varken inboxposten eller ändringen av räknaren. Om commit lyckas men den efterföljande kvittensen till brokern går förlorad kan E-42 komma igen. Den befintliga posten förhindrar då en ytterligare ökning till 8. Kvittensen till brokern ingår inte i själva den lokala databastransaktionen.
Idempotens beskriver den säkra effekten av upprepning; en inbox är ett möjligt implementationsmönster. En outbox sparar i stället utgående meddelanden tillsammans med den lokala ändringen. Inboxen ensam garanterar inte att ett externt HTTP-anrop utförs eller ett e-postmeddelande skickas exakt en gång. Lagringstiden för meddelande-ID:n måste passa det möjliga tidsfönstret för omleverans och återuppspelning; poster som tas bort för tidigt skyddar inte längre mot senare dubbletter.
Källor
Relaterade begrepp
- IdempotensEn idempotent åtgärd har samma avsedda effekt på tillståndet vid identisk upprepning som vid en enda körning.
- MeddelandekvittensEn meddelandekvittens talar om för brokern att en leverans har tagits emot eller behandlats enligt den överenskomna regeln.
- Jitter vid återförsökRetry-jitter varierar väntetider slumpmässigt för att sprida återförsök och minska samtidiga anrop från många klienter.
- TestkundmiljöEtt logiskt avgränsat kundområde i en multitenant-applikation, inrättat för kontroller.
- Omsändning av webhookOmsändning av webhook skickar ett meddelande igen. Avsiktlig återhämtning och replayattacker kräver olika kontroller.
- IdempotensnyckelEn idempotensnyckel identifierar upprepningar av samma avsedda begäran. Område, lagringstid och API-regler avgör dess verkan.
Artiklar om ämnet
API:er & integration med ASES
ERP, CRM och webbutik smidigt sammankopplade