Message Persistence
To ensure that the queue metadata and the messages within the queue are not lost after the Broker restarts, it is recommended to set the queue as durable and the messages as persistent. This way, the queue will immediately persist the messages to disk upon receiving them.
Non-persistent messages will also occupy more server-side memory resources, potentially causing high memory load on the server under extreme conditions.
Sender Confirmation
The Confirmation Mechanism can ensure that the message is successfully sent to the Broker. However, if the mandatory setting is not configured when sending the message, the Broker will respond with a confirm to the sender regardless of whether the message is successfully routed to the target queue. If the mandatory setting is configured (delayed exchange does not support the mandatory setting), the Broker will return the message to the client if it cannot be routed. The client can sense these unroutable messages by implementing basic.return handling; the Broker will only respond with a confirm to the sender when the message is successfully routed to the target queue.
Consumption End Acknowledgement
The ACK Mechanism at the consumption end ensures that the client receives the messages, providing at least once level consumption semantics guarantee, ensuring the message is correctly processed before it can be deleted. However, the client also needs to implement idempotence to avoid errors from consuming duplicate messages, and messages that are not ACKed will pile up in memory, increasing memory usage on both the client and server sides.
Enabling Image Queue
Image Queue ensures the high availability of the queue by replicating the queue data to other Brokers within the cluster. Configuring the image queue policy may increase Broker startup duration and resource usage, but it ensures that the queue remains available in the event of a single Broker failure, making every effort to prevent message loss.
When configuring the image queue policy, it is advisable to avoid setting ha-sync-mode=automatic, as this configuration will trigger automatic full synchronization of the queue data after the server-side Broker restarts (regardless of whether the queue data has been previously synchronized). If the queue accumulates too much data, it will eventually result in a prolonged synchronization time, continued memory resource usage, and the queue will remain unavailable until synchronization is complete. This has serious implications on business availability and server stability.