CodeParkPublisher confirms make the broker tell the publisher when it has safely taken each message. Durable queues and persistent messages alone don't give the publisher this feedback.
A durable queue survives a broker restart. A persistent message is written to disk. But a plain publish is fire-and-forget: the publisher sends the message and never hears back. Suppose the connection drops, or the broker fails before it stores the message. Then the publisher never finds out, and the message is lost.
Publisher confirms put the channel in confirm mode. The broker then sends an ack for each message once it has taken responsibility for it. For persistent messages to durable or quorum queues, this happens after the message is written to disk or copied to a majority (a quorum) of replicas. A nack means the broker could not handle the message.
In amqplib, call createConfirmChannel(). Then use either a callback for each message or waitForConfirms().
The publisher should keep unconfirmed messages and publish them again on a nack or a timeout. This can create duplicates, so consumers must be idempotent: handling the same message twice must have the same effect as handling it once. Confirm in batches or asynchronously. Waiting for each confirm one at a time is slow.
- Durable queues and persistent messages alone give the publisher no feedback.
- In confirm mode, the broker acks a message once it has taken responsibility for it.
- The ack comes after the message is on disk or replicated to a quorum.
- Republish unconfirmed messages, so consumers must remove duplicates.
- Confirm asynchronously or in batches for better throughput.