Message Receiving and Sending
l Message sending: You can specify synchronous or asynchronous sending. Identity authentication: SSL or password authentication is performed when clients connect to the RabbitMQ server. Broadcasting transmission; Both persistent and non-persistent messages can be sent.
l Message consumption mode: pull and push, and polling consumption among multiple consumers.
Reliable Message Sending
RabbitMQ uses transaction and the confirm mechanism to ensure reliability. Transactions help solve the problem of acking messages between a producer and a broker. A transaction is committed only when the message is received by the broker successfully, but it degrades performance. RabbitMQ provides a low-consumption way to manage transactions by setting the channel to confirm mode. A unique ordered ID (starting with 1) is generated for messages sent through a channel in the confirm mode. Once a message has been successfully sent to the queue, the RabbitMQ server sends the producer an ack containing the message ID. This way, the producer knows that the message has been sent successfully. The confirm mechanism supports the sender confirm, batch confirm, and asynchronous monitoring sender confirm modes for reliable and high-performance sending of messages.
Message Confirm
RabbitMQ provides a message ack mechanism to ensure that messages are reliably sent to consumers from queues.
l When a consumer subscribes to a queue, the autoAck parameter can be specified. When autoAck is set to true, RabbitMQ adopts the auto ack mode and automatically sets the messages that have been sent as acked ones and deletes them from the memory or hard disk without waiting for a confirmation from the consumer.
l When autoAck is set to false, RabbitMQ waits for a confirmation signal from the consumer before deleting the message from the memory or disk.
The message confirm mechanism is the basis for reliable delivery of messages in RabbitMQ. When autoAck is set to false, the consumer has enough time to process the message without worrying about message loss caused by a consumer process failure.
Message TTL
Time To Live (TTL) refers to the maximum time for which a message can exist in a queue. Unit: millisecond.
l You can configure TTL for messages and queues in RabbitMQ.
l In RabbitMQ, you can set the TTL of messages at the time of sending. Each message can be configured with a different TTL.
l RabbitMQ allows you to set a TTL for queues. The time is counted at the point when a message is delivered to the queue. If the time exceeds the TTL, the message becomes a dead letter and is automatically cleared.
l If you have set both TTLs, the expiration time with the smaller value prevails.
l TTLs are not mandatory. If you do not set a TTL, messages will not expire. If TTL is set to 0, messages are immediately discarded unless they are delivered directly to the consumer at this point.
Persistence
RabbitMQ provides persistence for exchanges, queues, and messages.
l Exchange persistence: Set the durable parameter to true when declaring queues. When the RabbitMQ service is restarted, the metadata of the exchange that is not set with persistence will be lost, but messages will not be lost. However, messages will not be sent to this exchange.
l Queue persistence: Ensures that the metadata of queues will not be lost due to abnormal conditions, but the messages stored internally may be lost. You need to set messages to persistent ones to avoid data loss. Queue persistence: Sets the durable parameter to true when declaring queues.
l You can set queues and messages to persistent ones so that messages will not be lost after the RabbitMQ service is restarted. If you only set queue or message persistence, messages will be lost after restart.
For less reliable messages, you can disable persistence to improve overall throughput. Therefore, you need to strike a balance between reliability and throughput based on actual conditions.
Delayed Queue
Generally, messages are consumed by consumers as soon as they are delivered to a queue. However, messages that are sent to a delayed queue are consumed after a specific time, and those messages are called delayed messages because they are consumed only after a specific time elapses. RabbitMQ provides TTL + dead-letter queue and delay queue to consume messages after a specific delay.
Dead-letter Queue
When a message becomes a dead one in a queue, the dead letter is re-sent to another exchange, which becomes a dead-letter exchange, and the queue bound to this exchange is called a dead-letter queue. A message becomes a dead one in the following scenarios:
l The message was rejected.
l The message expired.
l The queue reaches the maximum length.
Dead-Letter-Exchange (DLX) is an ordinary exchange, and can be specified on any queue. Specifically, you can set the properties of a queue. When the queue has a dead letter, RabbitMQ will automatically re-send the message to the exchange, from where it is routed to another queue. In case of an exception, the message cannot be consumed normally by the consumer and is added to the dead-letter queue. Subsequent programs can analyze the anomalies based on the content of the dead-letter queue to improve and optimize the system.
Priority Queue
In a priority queue, messages with higher priorities are placed in the head of the queue and are preferentially sent to consumers for processing.
RabbitMQ allows you to set the priority of messages. There are 10 levels of priorities and a greater level indicates a higher priority. Multiple messages with the same priority are sorted in FIFO order.
Mirror Queue
RabbitMQ uses mirror queues to store multiple copies of queues to different instance nodes. A queue has a master node and several slave nodes. For a queue, only the master node provides services, while other slave nodes only act as backup. If the master node is unavailable, a slave node is selected as the master to continue the services. The data is obtained from the master node regardless of whether the client sends requests to the master or slave node.
l When a request is sent to the master node, it directly returns the message to the client, and broadcasts the latest status of the queue to the slave node through the Guaranteed Multicast (GM) protocol. GM guarantees the atomicity of broadcast messages, i.e. either updating all or none.
l When a request is sent to the slave node, it redirects the request to the master node first, which returns the message to the client. At the same time, the master node broadcasts the latest status of the queue to the slave node through the GM protocol.