Meddelelseskvittering
En meddelelseskvittering fortæller brokeren, at en levering er modtaget eller behandlet efter den aftalte regel.
En meddelelseskvittering fortæller en message broker, hvornår en levering må betragtes som afsluttet. Det afgørende er kvitteringens retning, og hvornår applikationen sender den.
I RabbitMQ bekræfter en forbruger sin behandling over for brokeren med en manuel positiv kvittering som basic.ack. En publisher confirm bekræfter derimod over for afsenderen, at brokeren har accepteret meddelelsen. Det viser ikke, at modtagerapplikationen har afsluttet sin opgave.
Mellem lagring og kvittering
I et fiktivt forløb behandler en tjeneste meddelelsen E-42, gemmer den nødvendige databaseændring varigt og kvitterer derefter. Kvitterer den først og går ned før lagringen, kan brokeren allerede betragte leveringen som afsluttet, selv om ændringen mangler.
Det omvendte tilfælde er også vigtigt: Er ændringen gemt, men kvitteringen går tabt, kan meddelelsen blive leveret igen. Med manuelle kvitteringer lægger RabbitMQ ukvitterede meddelelser tilbage i køen, når forbindelsen eller kanalen lukkes. Tjenesten skal derfor kunne håndtere gentagelsen uden at skabe det samme forretningsresultat to gange.
Automatisk kvittering i RabbitMQ venter ikke på, at applikationens arbejde er færdigt. Den valgte tilstand skal passe til den ønskede beskyttelse mod tabt arbejde. En forbrugerkvittering beviser heller ikke, at alle efterfølgende tjenester eller en ekstern besked er lykkedes.
Kilder
Relaterede begreber
- BeskedkøEn beskedkø fungerer som buffer for beskeder, indtil en forbruger overtager dem til behandling.
- Transaktionel inboxEn transaktionel inbox bruger varige meddelelsesregistreringer til at beskytte lokal behandling mod dobbelte leveringer.
- Jitter ved genforsøgRetry-jitter varierer ventetider tilfældigt for at sprede genforsøg og mindske samtidige forespørgsler fra mange klienter.
- TestkundemiljøEt logisk afgrænset kundeområde i en multitenant-applikation, indrettet til kontroller.
- Genafsendelse af webhookGenafsendelse af webhook sender en meddelelse igen. Bevidst genopretning og replay-angreb kræver forskellige kontroller.
- IdempotensnøgleEn idempotensnøgle identificerer gentagelser af den samme tilsigtede anmodning. Område, opbevaring og API-regler bestemmer dens virkning.
Artikler om emnet








Snitflader & integration med ASES
ERP, CRM og webshop forbundet ordentligt

