ธุรกรรมกับการยืนยันจากผู้เผยแพร่

Persistent messages survive a broker restart, but persistence alone does not tell the publisher whether the broker actually received and stored the message.

For end-to-end reliability you need confirmation.

AMQP supports transactions on a channel: you begin a transaction, publish messages, then commit. The broker confirms the whole batch atomically.

Enable transaction mode with tx_select, publish, then tx_commit.

Transactions are synchronous and slow. Each commit blocks until the broker responds, often cutting throughput by 200x or more.

They serialize publishing, which kills pipelining.

Publisher confirms are an asynchronous alternative. The broker sends an ack per message (or per batch) once it is safely handled, without blocking the publisher.

Put the channel into confirm mode once; you cannot mix it with transaction mode on the same channel.

With confirms you can keep publishing while acks arrive in the background, then match acks to delivery tags. This preserves high throughput.

If the broker cannot handle a message it sends a nack. Your code must resend or log it. Nacks are rare but signal internal broker errors.

• Transactions: true atomic multi-message commit, but very slow
• Confirms: near-equivalent safety with far higher throughput

The RabbitMQ team recommends confirms for almost all cases.

For the strongest guarantee, mark messages persistent and use confirms; the broker only acks a persistent message after it is written to disk.

A single channel cannot be in both transaction and confirm mode. Pick one per channel; attempting both raises a channel error.

Test your reliability knowledge.

Both transactions and publisher confirms tell a publisher the broker accepted a message.

Transactions are atomic but slow; confirms are asynchronous and fast. Combine confirms with persistent messages for the best balance of reliability and performance.