Co jsou publisher confirms v RabbitMQ?

Question

Accepted Answer

**Publisher confirms** jsou mechanismem, kterým RabbitMQ potvrzuje výrobci, že obdržel (a uložil) zprávu — zajišťují, že zprávy nejsou ztraceny na straně vydavatele. Jsou protějškem potvrzování spotřebitelů na straně výrobce.

## Problém: dosáhla zpráva brokera?

```text
When a producer publishes a message, by default it doesn't KNOW if RabbitMQ received it:
  → network failure, broker issue → the message could be LOST without the producer knowing
  → for reliability, the producer needs CONFIRMATION that the message was accepted
→ publisher confirms address the PUBLISHING side of reliability
```

## Jak fungují publisher confirms

```text
PUBLISHER CONFIRMS → the broker sends an ACK back to the producer for each message:
  → enable confirm mode on the channel
  → the broker ACKs a message once it has taken responsibility (received it; for persistent
    messages on durable queues → once persisted to disk)
  → NACK → the broker couldn't handle the message (the producer can retry)
→ the producer KNOWS each message was accepted (or not) → no silent loss
```

## Používání confirms

```text
✓ Wait for confirms (sync) → simple but slower; or handle confirms ASYNCHRONOUSLY (callbacks)
  for throughput (don't block on each)
✓ Batch confirms → confirm batches for better throughput
✓ On NACK/timeout → retry the message (with idempotency awareness)
→ combine with durable queues + persistent messages → reliable end-to-end publishing
```

## Proč je to důležité

Rozeznání publisher confirms je cenné, protože jsou **nezbytné pro spolehlivost na straně publikování v RabbitMQ**, takže je důležité je znát při budování spolehlivého zasílání zpráv.

Publisher confirms řeší klíčskou mezeru v spolehlivosti: standardně, když výrobce publikuje zprávu, neví, zda ji RabbitMQ skutečně obdržel, takže selhání sítě nebo problém brokera by mohl **ztratit zprávu bez vědomí výrobce** — skutečný problém se spolehlivostí na straně publikování.

Rozeznání **jak fungují publisher confirms** — broker posílá **ack zpět výrobci** pro každou zprávu, jakmile si vezme odpovědnost (obdrží ji, nebo pro trvalé zprávy na trvalých frontách, jakmile ji uloží na disk), s **nack**, pokud broker nemohl zprávu zvládnout (aby si výrobce mohl zprávu poslat znovu) — objasňuje mechanismus, který výrobci dává potvrzení, zabraňující tiché ztrátě zpráv při publikování.

Jde o **protějšek potvrzování spotřebitelů na straně výrobce** (které chrání stranu spotřeby), společně poskytují koncovou spolehlivost.

Rozeznání **používání confirms** — čekání na confirms synchronně (jednoduché, ale pomalejší) versus jejich zpracování asynchronně pomocí callbacků (pro propustnost), dávkování confirms a opakovaný pokus o odeslání při nack/timeout (s vědomím idempotentnosti) — odráží praktické, efektivní používání.

Rozeznání, že kombinování publisher confirms s trvalými frontami a trvalými zprávami poskytuje spolehlivé koncové publikování, spojuje confirms s širší spolehlivostí (confirms na straně publikování, trvalost pro úložiště, acks pro spotřebu).

Publisher confirms jsou nezbytné pro zajištění, že zprávy dosáhnou brokera spolehlivě, důležitá součást spolehlivého zasílání zpráv často opomíjená (lidé se zaměřují na consumer acks, ale zapomínají na spolehlivost na straně publikování).

Protože publisher confirms jsou nezbytné pro spolehlivost na straně publikování (zajištění, že zprávy dosáhnou brokera, zabraňují tiché ztrátě) — protějšek consumer acks na straně výrobce — a jejich porozumění je důležité pro koncovou spolehlivé zasílání zpráv, rozeznání publisher confirms je cenné, prakticky relevantní znalosti RabbitMQ — nezbytné pro spolehlivost na straně publikování (zabraňuje tiché ztrátě zpráv při publikování), doplňuje obraz spolehlivosti spolu s consumer acks a trvalostí, a je důležité pro budování spolehlivých systémů RabbitMQ s koncovými zárukami doručení.