Basic Concepts of RabbitMQ

There are four very important concepts in AMQP:
virtual host virtual host
exchange exchange
queue queue
binding binding A virtual host holds a set of exchanges, queues and bindings.

3. Message acknowledgment (ACK)
In practical applications, it may happen that the consumer receives the message in the Queue, but crashes (or other accidents) without processing it. In this case, it may lead to Message lost. In order to avoid this situation, we can ask the consumer to send a receipt to RabbitMQ after consuming the message, and RabbitMQ will remove the message from the Queue after receiving the message acknowledgment; if RabbitMQ does not receive the receipt and Detecting that the consumer's RabbitMQ connection is disconnected, RabbitMQ will send the message to other consumers (if there are multiple consumers) for processing. There is no timeout concept here, and a consumer processing a message for a long time will not cause the message to be sent to other consumers unless its RabbitMQ connection is disconnected.
Another problem will arise here. If our developers forget to send a receipt to RabbitMQ after processing the business logic, this will lead to serious bugs - more and more messages will accumulate in the Queue; Consume these messages repeatedly and execute business logic repeatedly.

4. Message persistence
If we hope that the message will not be lost even when the RabbitMQ service is restarted, we can set both Queue and Message to be durable, which can ensure that our RabbitMQ messages will not be lost in most cases . But it still can't solve the occurrence of small probability loss events (for example, the RabbitMQ server has received the message from the producer, but the RabbitMQ server is powered off before it has time to persist the message), if we need to deal with such small probability events To manage, then we need to use the transaction or confirm mechanism .

4.1 Transactions
Support for transactions is an important feature of the AMQP protocol. Suppose that when the producer sends a persistent message to the server, because the consume command itself does not return any Response, even if the server crashes and the message is not persisted, the producer cannot know that the message has been lost. If you use a transaction at this time, that is, open a transaction through txSelect(), then send a message to the server, and then submit the transaction through txCommit(), you can guarantee that if txCommit() is committed, the message will be persistent, if If txCommit() has not been submitted, the server crashes, and the message will not be received by the server. Of course, Rabbit MQ also provides the txRollback() command to roll back a transaction.

4.2 Confirm mechanism
Using transactions can certainly ensure that only committed transactions will be executed by the server. But this also synchronizes the client with the message server, which departs from the essence of message queue decoupling. Rabbit MQ provides a more lightweight mechanism to ensure that the producer can sense whether the server message has been routed to the correct queue - Confirm. If the channel is set to the confirm state, the message sent through the channel will be assigned a unique ID, and then once the message is correctly routed to the matching queue, the server will return a Confirm to the producer, the Confirm contains the The ID of the message, so the producer will know that the message has been dispatched correctly. For persistent messages, Confirm will be returned only after the message is persisted. The biggest advantage of the Confirm mechanism is that it is asynchronous, and the producer can continue to perform other tasks after sending the message. After the server returns Confirm, it will trigger the producer's callback function, and the producer processes the Confirm information in the callback function. If the message server is abnormal and the message is lost, a nack will be returned to the producer, indicating that the message has been lost, so that the producer can resend the message to ensure that the message is not lost. Confirm mechanism is much better than transaction in performance. However, the Confirm mechanism cannot be rolled back, that is, once the server crashes, the producer cannot get the Confirm information, and the producer itself does not know whether the message has been persisted, and can only continue to resend to ensure that the message is not lost, but if the original Messages that have been persisted will not be rolled back, so there will be two identical messages in the queue, and the system needs to support deduplication.

5. Prefetch count
Earlier we mentioned that if multiple consumers subscribe to messages in the same Queue at the same time, the messages in the Queue will be shared among multiple consumers. At this time, if the processing time of each message is different, it may cause some consumers to be busy all the time, while other consumers quickly finish the work at hand and remain idle. We can limit the number of messages that the Queue sends to each consumer each time by setting prefetchCount. For example, if we set prefetchCount=1, the Queue sends a message to each consumer at a time; after the consumer processes the message, the Queue will Send another message to the consumer.

6. The Exchange
Producer delivers the message to the Queue, which in fact never happens in RabbitMQ. The actual situation is that the producer sends the message to the Exchange, and the Exchange routes the message to one or more Queues (or discards it).
There are four types of Exchange in RabbitMQ, and different types have different routing strategies.

6.1 Routing key
When sending a message to Exchange, a routing key producer generally specifies a routing key to specify the routing rules for the message, and this routing key needs to be used in conjunction with the Exchange Type and the binding key to take effect.
In the case where the Exchange Type and the binding key are fixed (in normal use, these contents are generally fixedly configured), our producer can determine where the message flows by specifying the routing key when sending a message to the Exchange.
The length limit set by RabbitMQ for the routing key is 255 bytes.

6.2 Exchange Types
The commonly used Exchange Types of RabbitMQ are fanout, direct, topic, and headers, which are introduced separately below.
6.2.1 Fanout
The fanout type of Exchange routing rules is very simple, it will route all messages sent to the Exchange to all the Queues bound to it.
6.2.2
The exchange routing rules of direct direct type are also very simple. It will route messages to those Queues whose binding keys exactly match the routing keys.
6.2.3 As mentioned earlier in topic 6.2.3
, the direct-type Exchange routing rule completely matches the binding key and routing key, but this strict matching method cannot meet actual business requirements in many cases. Exchange of topic type is extended on the matching rules, which is similar to Exchage of direct type, and also routes messages to the Queue whose binding key matches the routing key.
6.2.4 headers
Exchange of headers type does not rely on the matching rule between routing key and binding key to route messages, but matches according to the headers attribute in the content of the sent message.
Specify a set of key-value pairs when binding Queue and Exchange; when a message is sent to Exchange, RabbitMQ will get the headers of the message (also in the form of a key-value pair), and compare whether the key-value pair exactly matches Queue and The key-value pair specified when the Exchange is bound; if it matches exactly, the message will be routed to the Queue, otherwise it will not be routed to the Queue.