Persistence
To ensure that queue metadata and messages in the queue are not lost after a broker restart, it is recommended to set queues to durable and messages to persistent. This ensures that messages are immediately persisted to the disk after being received by the queues.
Non-persistent messages occupy more memory, which may increase server memory load. It is recommended to set exchanges to durable to avoid metadata loss after the broker starts.
Sender Confirmation
The Confirm mechanism ensures that messages are successfully sent to the broker. However, if mandatory is not set when messages are sent, the broker will respond with Confirm to the sender regardless of whether the messages are successfully routed to any queue. If mandatory is set (it cannot be set for delayed exchanges), the broker will return the message that cannot be routed to the client via the original path. The client can detect and process these unroutable messages through implementing basic.return. Only when messages are successfully routed to the target queue will the broker respond with Confirm to the sender.
Consumer Acknowledgment
The consumer acknowledgment mechanism can ensure that messages are received by the client and provide at least once consumption semantics guarantee, ensuring that the message can only be deleted after being correctly processed. However, this also requires the client to implement idempotency to avoid errors caused by repeated consumption of messages. Additionally, unacknowledged messages will accumulate in memory, increasing memory usage on both the client and the server.
Enabling Mirrored Queues
Mirrored queues ensure high availability by replicating queue data to other brokers in the cluster. Configuring mirrored queue policies may increase broker startup time and resource usage, but it ensures that queues remain available in case of a single broker failure, minimizing message loss.
When configuring mirrored queue policies, avoid setting ha-sync-mode=automatic. This setting causes the broker of the server to perform a full synchronization of the queue data automatically after a restart (regardless of whether the queue data has been previously synchronized). If there is a large backlog of data in the queue to be synchronized, it will lead to issues such as prolonged broker data synchronization time and continuous memory usage. The queue is unavailable until the queue synchronization is completed, which can severely impact business availability and server stability.