- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- Practical Tutorial
- API Documentation
- SDK Documentation
- FAQs
- General References
- Service Level Agreement
- Contact Us
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- Practical Tutorial
- API Documentation
- SDK Documentation
- FAQs
- General References
- Service Level Agreement
- Contact Us
RabbitMQ Message Reliability Practical Tutorial
Last updated: 2024-09-10 14:37:18
Message Persistence
To ensure the queue metadata and messages in the queue are not lost after the Broker restarts, it is recommended to set the queue to durable and the messages to persistent. Then the queue will immediately persist the messages to disk upon receiving them.
Non-persistent messages will also occupy more server memory resources, which can, in extreme cases, lead to high memory load on the server.
Sender Confirm
The Confirm mechanism ensures messages are successfully sent to the Broker. However, if the mandatory is not set when a message is sent, the Broker will respond with confirm to the sender regardless of whether the message is successfully routed to the target queue. If the mandatory is set (note that the delay exchange does not support setting mandatory), and the message cannot be routed, the Broker will return the message to the client. The client can detect these unroutable messages by implementing basic.return; only when the message can be successfully routed to the target queue will the Broker respond with confirm to the sender.
Consumer Acknowledgement
The ACK mechanism on the consumer side ensures that messages are received by the client and provides an at least once consumption semantics guarantee, ensuring the message can only be deleted after being correctly processed. However, this also requires the client to implement idempotency to avoid errors caused by duplicate message consumption. Additionally, unacknowledged messages will accumulate in memory, increasing memory usage on both the client and server.
Enabling Image Queues
Image queues ensure high availability by replicating queue data to other Brokers in the cluster. Configuring image queue policies may increase the Broker's startup duration and resource usage, but it can ensure that the queue remains available in the event of a single Broker failure, minimizing message loss.
When image queue policies are configured, avoid setting ha-sync-mode=automatic, as this configuration will cause the server Broker to automatically perform a full synchronization of the queue data after a restart regardless of whether the data has already been synchronized. If the synchronized queue has too much data heap, it will result in prolonged Broker synchronization time, continuous memory usage, and other issues. Additionally, the queue will be unavailable until the synchronization is complete, severely affecting both business availability and server stability.
Yes
No
Was this page helpful?