Hvordan fungerer beskedbekræftelser (message acknowledgments) i RabbitMQ?

Question

Accepted Answer

**Bekræftelser (acks)** fortæller RabbitMQ, at en besked er blevet behandlet med succes, så den kan fjernes fra køen. De er essentielle for **pålidelig levering** — sikrer, at beskeder ikke går tabt, hvis en consumer fejler.

## Sådan fungerer bekræftelser

```text
When a consumer receives and processes a message, it ACKNOWLEDGES it:
  → ACK → "I've processed this message" → RabbitMQ removes it from the queue
  → if a consumer DIES before acking (crash, disconnect) → RabbitMQ REQUEUES the message
    → redelivered to another consumer (NOT lost)
→ acks ensure messages are processed reliably (not lost if a consumer fails)
```

## Manuelle versus automatiske acks

```text
MANUAL ack → the consumer explicitly acks AFTER processing → reliable (message redelivered
  if processing fails) — the safe choice for important messages
AUTOMATIC ack → the message is considered acked as soon as it's DELIVERED (before processing)
  → faster but UNSAFE → if the consumer crashes during processing, the message is LOST
→ use MANUAL acks for reliability (ack only after successful processing)
```

## Negative acks og afvisning

```text
✓ NACK / REJECT → the consumer can negatively acknowledge a message it can't process:
  → REQUEUE it (try again / another consumer) OR send it to a DEAD LETTER queue
  → handle messages that fail processing (don't lose them, don't block forever)
→ acks (positive and negative) give control over message handling and reliability
```

## Hvorfor det betyder noget

At forstå beskedbekræftelser er fundamental, fordi de er **essentielle for pålidelig levering i RabbitMQ**, så det er vigtig viden for at bygge pålidelige messaging-systemer.

Bekræftelser er måden, RabbitMQ sikrer, at beskeder behandles pålideligt.

At forstå **hvordan bekræftelser fungerer** — en consumer der acker en besked efter behandling (fortæller RabbitMQ, at den er færdig, så beskeden fjernes), med beskeder **der sættes tilbage i kø og sendes igen, hvis en consumer dør før acking** (så beskeder ikke går tabt ved consumer-fejl) — præciserer den pålidelighedsmekanisme, der forhindrer meddelelsetab.

At forstå **manuelle versus automatiske acks** er afgørende: **manuelle acks** (consumeren explicitly acker efter behandling, så beskeder sendes igen, hvis behandlingen fejler — det sikre, pålidelige valg) versus **automatiske acks** (beskeden anses for acked, så snart den er leveret, før behandling, hvilket er hurtigere men **usikkert**, da et nedbrud under behandling mister beskeden).

Den vigtige praktiske vejledning er at **bruge manuelle acks for pålidelighed** (acking kun efter vellykket behandling), da automatiske acks risikerer meddelelsetab — en almindelig, vigtig overvejelse.

At forstå **negative acks og afvisning** — en consumer der negativt bekræfter (nack/reject) en besked, som den ikke kan behandle, enten sætter den tilbage i kø eller sender den til en **dead letter queue** — giver kontrol over håndtering af mislykkede beskeder (uden at miste dem eller blive blokeret for evigt).

Disse bekræftelsesmekanismer (positive acks for pålidelig levering, manuelle acks for sikkerhed, negative acks til fejlhåndtering) er essentielle for at bygge pålidelig RabbitMQ-messaging, der ikke mister beskeder.

Da bekræftelser er essentielle for pålidelig levering i RabbitMQ (forhindrer meddelelsetab ved consumer-fejl, hvor manuelle acks er det sikre valg, og negative acks håndterer fejl), og da forståelse af dem er vigtig for at bygge pålidelig messaging, er forståelse af beskedbekræftelser essentiel, grundlæggende RabbitMQ-viden — central for pålidelig levering (sikrer, at beskeder ikke går tabt, hvis consumere fejler), hvor adskillelsen mellem manuel og automatisk acking er en vigtig pålidelighedsovervejelse, og nødvendig for at bygge pålidelige RabbitMQ-systemer.