Some concepts of message transmission have been mentioned many times in the previous article. This article will give a more comprehensive introduction, and then add some content.
reply to message
RabbitMQ has two reply modes, automatic and manual. This is also recommended by the AMQP protocol. This is the same in point-to-point and broadcast.
Automatic response - When RabbitMQ sends a message to the receiver, the receiver will automatically send a response message to the service for you when the message is dequeued.
Manual acknowledgment - requires our developers to manually call the ack method to tell the service that it has been received.
The document recommends that in big data transmission, if you are not very sensitive to the loss of individual messages, it is ideal to use automatic response, and for those scenarios where no message can be lost, you need to use manual response, that is, only after correct processing is completed. . If automatic answering is selected, then the function of message resending is not available.
Rejection of messages
Rejection is a command that the receiving end responds to the RabbitMQ service when it receives a message, telling the server that it should not be handled by me, or refuse to handle it and throw it away. The receiver can choose whether to put it back in the queue when sending the reject command. Be aware of the danger of sending in an infinite loop if there are no other receivers monitoring the queue.
BasicDeliverEventArgs ea = (BasicDeliverEventArgs)consumer.Queue.Dequeue();
channel.BasicReject(ea.DeliveryTag, false);
The first parameter of the BasicReject method is the DeliveryTag of the message. For each Channel, each message will have a DeliveryTag, which is generally represented by the order in which the messages are received: 1, 2, 3, 4, and so on. The second parameter is whether to put it back in the queue, requeue.
BasicReject can only refuse to receive one message at a time, while the BasicNack method can support the rejection of 0 or more messages at a time, and can also set whether to requeue.
channel.BasicNack(3, true, false);
If you enter 3 in the first parameter DeliveryTag, if the message DeliveryTag is less than or equal to 3, this Channel will be rejected.
QoS of messages
QoS = quality-of-service, as the name suggests, the quality of service. Usually when we design a system, we cannot completely eliminate faults or guarantee that there is no fault, but should design a complete exception handling mechanism. When an error occurs, knowing where and what kind of error occurred, what is the cause, and how to recover or deal with it is the real thing to do. When the received message fails, we can handle it through the RabbitMQ retransmission mechanism. Retransmission has a limit on the number of retransmissions. Sometimes you cannot retransmit an unlimited number of times, depending on the size, importance and processing of the message.
Even QoS is set at the receiving end. There is no change on the sender side, and the code on the receiver side is relatively simple, just add the following code:
channel.BasicQos(0, 1, false);
The first parameter of the code is the size of the message that can be received, but it seems that in client version 2.8.6 it must be 0, even: unlimited. If you do not lose 0, the program will report an error when it runs to this line, saying that the case where it is not 0 has not been implemented. The second parameter is the maximum number of messages to process. For example, if you enter 1, then if a message is received, but there is no response, the client will not receive the next message, and the message will just block in the queue. If you enter 3, then there can be up to 3 messages that do not respond. If 3 messages are reached, the message sent by the sender to the receiver will only be in the queue, and the receiver will not have an event to receive the message. In summary, it is the maximum number of messages that the client can receive before the next reply message is sent. The third parameter sets whether it is for the entire Connection, because a Connection can have multiple Channels. If it is false, it means that it is only for this Channel.
This number of settings also provides us with more options in a load balancing environment where multiple clients monitor the same queue.