Please point out any inadequacies in RabbitMQ tutorials.
Let’s take a look at the flow of a message through RabbitMQ
The main process shown in the diagram is as follows
There are basically four participants in the process: Message, Exchange, Queue, and consumer, so let’s take a look at these four participants
A message can set a list of properties
Receives a message and forwards it to the bound queue based on the routing key. Common attributes are as follows
The most commonly used attribute is the Type attribute, which is explained in detail below
Messages sent to the switch are routed to all queues bound to the switch and can be used for broadcasting
Instead of dealing with routing keys, you simply bind the queue to the switch
The Fanout switch is the fastest to forward messages
Route messages to queues where BindingKey and RoutingKey exactly match
As mentioned earlier, a direct exchange routing rule matches RoutingKey and BindingKey exactly. Topic is similar to Direct in that it sends messages to queues that match RoutingKey and BindingKey, but with fuzzy matching.
If there are now two routingkeys java.lang and java.util.Concurrent messages, java.lang is routed to Consumer1 and Consumer2, Java.util.concurrent is routed to Consumer2.
A HEADERS exchange does not rely on the matching rules of the routing key to route a message, but matches it based on the HEADERS attribute in the content of the sent message. Headers switches have poor performance, are not practical, and are rarely used.
The common attributes of queues are as follows
Common queue parameters that can be set in Arguments are as follows
Review the various Exchange machine routing rules described above
Messages can be obtained in two ways
So should we pull or push a message? Get is a polling model, and consumer is a push model. The GET model causes the cost of synchronous communication with RabbitMQ for each message, which consists of the client application sending the request frame and the RabbitMQ sending the reply. So push messages, avoid pulling
There are two ways to confirm a message
A consumer can specify an autoAck parameter when consuming a message
String basicConsume(String queue, boolean autoAck, Consumer callback)
AutoAck =false: RabbitMQ will wait for the consumer to display a reply acknowledgement before removing the message from memory (or disk)
AutoAck =true: RabbitMQ will automatically set the sent messages to acknowledgement and delete them from memory (or disk), regardless of whether the consumer actually consumes them
The method of manual confirmation is as follows. There are two parameters
basicAck(long deliveryTag, boolean multiple)
DeliveryTag: Identifies the message delivered in the channel. RabbitMQ pushes a message to a Consumer with a deliveryTag so that the Consumer can tell RabbitMQ which message was confirmed when the message is confirmed. RabbitMQ guarantees that each message’s deliveryTag increases by 1 on each channel
Multiple =true: all messages with id<=deliveryTag will be confirmed
Myltiple =false: Messages with id=deliveryTag will be acknowledged
What happens when the message is never confirmed?
If a message in the queue is sent to a consumer and the consumer does not acknowledge the message, it remains in the queue until it is confirmed and deleted. If the message sent to consumer A remains unacknowledged, RabbitMQ will not consider redelivering consumer A’s unacknowledged message to another consumer until consumer A’s connection to RabbitMQ is disconnected
There is only one way to confirm a message
There are two ways to reject a message
There is only one difference between basicNack and basicReject. BasicNack supports batch rejection
The deliveryTag and multiple parameters were mentioned earlier.
Requeue =true: The message is sent to the queue again
Requeue =false: The message will be lost directly
Chapter_6 through chapter_10 briefly describe trade-offs when publishing messages
The most common ones are failure notifications and publisher confirmations. How do we get messages that can’t be routed to a queue?
Mandatory is an argument in channel.basicPublish()
Mandatory =true: If the switch cannot find a queue that matches the criteria based on the routing key, RabbitMQ will call basic. Return to Return the message to the producer
Mandatory =false: The message is discarded
When a message is sent, does it reach the Exchange at all? By default, the producer does not know if the message has reached the Exchange
RabbitMQ provides two solutions to this problem
Publishers confirm that there are three ways to program
Asynchronous Confirm mode has the highest performance and is often used, so I want to share this in detail
If you have written asynchronous confirm code, you should be familiar with this code. There is also deliveryTag and multiple in this code. But I should say that deliveryTag here has nothing to do with multiple and ack of messages.
Ack in confirmListener: controlled by RabbitMQ to confirm whether a message has arrived at the Exchange
Ack of messages: You can confirm either automatically or manually that a message in the queue has been consumed by a consumer
If mandatory is not set when a producer sends a message, the message will be lost without being routed to the queue. If mandatory is set, the programming logic of the ReturnListener needs to be added, and the producer code becomes complicated. If you don’t want to complicate the producer’s programming logic, but don’t want messages to get lost, you can use an alternate exchange that stores messages that are not routed to the queue in RabbitMQ and processes them as needed
There are three methods associated with transactions in RabbitMQ
The transaction must be successfully committed if the message is successfully sent to RabbitMQ’s exchange. Otherwise, the transaction can be rolled back after the exception is caught and the message can be resold at the same time. As transactions can drain RabbitMQ’s performance, a publisher confirmation is usually used instead of a transaction
To persist messages, simply set the delivery-mode of the message attribute to 2
The RabbitMQ encapsulates the attributes to us, namely MessageProperties. PERSISTENT_TEXT_PLAIN, use can reference lot code in detail
When we want to persist messages, it is best to set the queue and message persistence at the same time, because if we only set the queue persistence, the message will be lost after the restart. Only set the persistence of the queue. After the restart, the queue disappears and the message is lost
DLX, which stands for dead-letter-exchange, is called a Dead Letter Exchange. When a message becomes dead message in a queue, it can be re-sent to another exchange, the DLX. The queue bound to the DLX is called a dead letter queue. The DLX is also a normal exchange, no different from a normal exchange, which actually sets the attributes of a queue
There are several reasons why messages become dead-letter
The difference between dead letter and standby switches
Standby switch: 1. Messages are forwarded to the standby switch when they cannot be routed. 2. The standby switch is defined when the primary switch is declared
Dead letter exchange: 1. Messages that have reached the queue but have been rejected by consumers are forwarded to the dead letter exchange. 2. Dead letter switches are defined when queues are declared
Qos is traffic limiting on the server. Qos does not apply to pull-mode consumption
You only need to perform the following two steps to use qos
basicQos(int prefetchSize, int prefetchCount, boolean global)
I get more Java architecture information, source code and notes for free
