Meldingskvittering
En meldingskvittering forteller meldingsmegleren at en levering er mottatt eller behandlet etter den avtalte regelen.
En meldingskvittering forteller en meldingsbroker når den kan regne en levering som avsluttet. Retningen på kvitteringen og tidspunktet applikasjonen sender den på, er avgjørende.
I RabbitMQ bekrefter en konsument behandlingen sin overfor brokeren med en manuell positiv kvittering som basic.ack. En publisher confirm bekrefter derimot overfor avsenderen at brokeren har akseptert meldingen. Det viser ikke at mottakerapplikasjonen har fullført oppgaven sin.
Mellom lagring og kvittering
I et fiktivt forløp behandler en tjeneste meldingen E-42, lagrer den nødvendige databaseendringen varig og kvitterer deretter. Kvitterer den først og krasjer før lagringen, kan brokeren allerede regne leveringen som avsluttet, selv om endringen mangler.
Det motsatte tilfellet er også viktig: Hvis endringen er lagret, men kvitteringen går tapt, kan meldingen bli levert på nytt. Med manuelle kvitteringer legger RabbitMQ ukvitterte meldinger tilbake i køen når forbindelsen eller kanalen lukkes. Tjenesten må derfor håndtere gjentakelsen uten å skape det samme forretningsresultatet to ganger.
Automatisk kvittering i RabbitMQ venter ikke på at applikasjonens arbeid er ferdig. Den valgte modusen må passe til ønsket beskyttelse mot tapt arbeid. En konsumentkvittering beviser heller ikke at alle etterfølgende tjenester eller en ekstern varsling har lyktes.
Kilder
Beslektede begreper
- MeldingskøEn meldingskø fungerer som buffer for meldinger til en konsument henter dem for behandling.
- Transaksjonell inboxEn transaksjonell inbox bruker varige meldingsregistreringer for å beskytte lokal behandling mot doble leveringer.
- Jitter ved nye forsøkRetry-jitter varierer ventetider tilfeldig for å spre nye forsøk og redusere samtidige forespørsler fra mange klienter.
- TestkundeområdeEt logisk avgrenset kundeområde i en multitenant-applikasjon, satt opp for kontroller.
- Ny sending av webhookNy sending av webhook overfører en melding på nytt. Planlagt gjenoppretting og replay-angrep krever ulike kontroller.
- IdempotensnøkkelEn idempotensnøkkel identifiserer gjentakelser av samme tilsiktede forespørsel. Område, lagringstid og API-regler avgjør virkningen.
Artikler om temaet








API-er og integrasjon med ASES
ERP, CRM og nettbutikk ryddig koblet sammen

