RABBITMQ Series II (build Message Queuing)

As can be seen from the AMQP protocol, MessageQueue, Exchange, and binding form the core of the AMQP protocol. Here we take a comprehensive look at the three main components, from the perspective of application use, to build message queues and the considerations in using RABBITMQ.

Statement MessageQueue:

In RABBITMQ, whether a producer sends a message or a consumer receives a message, it first needs to declare a MessageQueue. Is there a question of whether the producer statement or the consumer statement? To solve this problem, first make clear:

1) The consumer is unable to subscribe or obtain information in the MessageQueue that does not exist.

2) After the message is received by Exchange, if there is no matching queue, it is discarded.

After understanding the above two points, it is easy to understand that if a consumer declares a queue, there is a risk that the message that the producer has sent is discarded before the queue is declared. If your app allows messages to be lost through a mechanism that sends a message back, there's no problem with using this scenario. However, if the scheme is not acceptable, it will need to try to establish a message queue before sending or receiving messages, whether it is a producer or a consumer. Here's one thing to be clear, if the client tries to establish a message queue that already exists, RABBITMQ will not do anything and return the client to build successfully.

If a consumer is listening to a queue's message in a channel, RABBITMQ does not allow the consumer to declare the other queue in the same channel. RABBITMQ, you can declare a queue with the Queue.declare command, and you can set the queue properties:

1) Exclusive: Exclusive queue, if a queue is declared as an exclusive queue, the queue is only visible to the connection that first declares it, and is automatically deleted when the connection is broken. There are three points to note here: First, the exclusive queue is visible based on the connection, and the different channels of the same connection can simultaneously access the exclusive queue created by the same connection. Second, for the first time, if a connection has declared an exclusive queue, the other connection is not allowed to establish an exclusive queue of the same name, which is different from the normal queue. Third, even if the queue is persisted, once the connection is closed or the client leg is thick, the exclusive queue will be automatically deleted. This queue applies to scenarios where only one client sends a read message.

2) Auto-delete: Automatic deletion, if the queue does not have any subscriptions to the consumer, the queue will be automatically deleted. This queue applies to temporary queues.

3) Durable: persistence, this will be in the back as a special discussion.

Other options, such as if the user simply wants to query whether a queue already exists, if it does not exist, and does not want to establish the queue, You can still call Queue.declare, except that you need to set the parameter passive to true, pass it to Queue.declare, return true if the queue already exists, and return error if it does not exist, but not create a new queue.

Producers send messages:

In the AMQP model, Exchange is a critical component that receives producer messages and routes messages to Message Queuing. ExchangeType and binding determine the routing rules for messages. So the producer wants to send a message, it must first declare an exchange and the corresponding binding for that exchange. Can be done through Exchangedeclare and Bindingdeclare. In RABBITMQ, there are three types of exchange:direct, fanout, and topic, and different exchange shows different routing behavior. Durable is the persistent property of exchange, which is discussed in the Message Persistence section. Declaring a binding requires providing a queuename,exchangename and a bindingkey.

Consumer Subscription Message:

In RABBITMQ, there are 2 ways consumers get messages in a queue:

A) one is to subscribe to a message in a queue via the Basic.consume command, and the channel automatically receives the next message after the last message is processed. (The same channel message processing is serial). The client will receive messages from the queue until the channel is closed or the subscription is canceled.

b) Another way is to actively obtain the messages in the queue through the Basic.get command, but it is absolutely not possible to call Basic.get in lieu of basic.consume by looping, because Basic.get rabbitmq is actually executing, is to first consume a queue, then retrieve the first message, and then cancel the subscription. If you are a high-throughput consumer, it is advisable to use Basic.consume.

If more than one consumer subscribes to the same queue at the same time, RABBITMQ distributes the message in a circular fashion, and each message can be received by only one subscriber.

After receiving the message, the consumer needs to send a confirmation command to the server. If the consumer disconnects the connection before it has time to return an ACK after receiving the message, the message server will retransmit the message to the next subscriber, and the message will be stored without the subscriber.

Since RABBITMQ provides a command to ACK a message, it also provides a command to reject a message. When a client error occurs, the call to the Basic.reject command rejects a message, you can set a Requeue property, and if true, the message server will retransmit the message to the next subscriber, or, if False, the message will be deleted directly. Of course, there is an ACK that allows the message server to delete the message directly and not retransmit it.

Persistence:

RABBITMQ default is non-durable queues, Exchange, binding, and messages in queues, which means that once the message server restarts, all declared queues, exchange,binding, and messages in the queue are lost. By setting the durable property of Exchange and Mesagequeue to true, you can make the queue and exchange persistent, but this does not make the message persisted in the queue, which requires the producer to set the delivery mode to 2 when sending the message. Only these three settings are complete to ensure that the server restart does not affect existing queues. It is important to note that only durable is true for Exchange and durable is true for queues to bind, otherwise RABBITMQ will error when binding. Persistence has a large impact on the performance of RABBITMQ, which can be reduced by more than 10.

Transaction:

Support for transactions is an important feature of the AMQP protocol. Suppose that when a producer sends a persistent message to the server, because the consume command itself does not have any response returned, the producer cannot know that the message has been lost even if the server crashes without persisting the message. If a transaction is used at this time, that is, a transaction is opened through Txselect (), then a message is sent to the server, and then the transaction is committed through Txcommit (), it is guaranteed that if Txcommit () commits, the message will be persisted if Txcommit () The server crashes when it is not committed, and the message is not received by the server. Of course RABBITMQ also provides the txrollback () command for rolling back a transaction.

Confirm mechanism:

Using transactions is a guarantee that only committed transactions will be executed by the server. However, this also synchronizes the client with the messaging server, which deviates from the Message Queuing decoupling book. RABBITMQ provides a more lightweight mechanism to ensure that a producer can perceive whether a server message has been routed to the correct queue in--confirm. If the channel is set to the confirm state, the message sent through the channel is assigned a unique ID, and once the message is correctly routed to the matching queue, the server returns to the producer a confirm that confirm contains the ID of the message So that the producer knows that the message has been distributed correctly. For persistent messages, confirm is returned only if 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. When the server returns confirm, the producer's callback function is triggered, and the producer processes the confirm information in the callback function. If an exception occurs on the message server, which causes the message to be lost, it is returned to the producer with an ACK indicating that the message has been lost so that the producer can send a message again to ensure that the message is not lost. The confirm mechanism is much better than the transaction in performance. However, the confirm mechanism, can not be rolled back, that is, once the server crashes, the producer can not get confirm information, the producer actually does not know that the message has been persisted, only to continue to re-send to ensure that the message is not lost, but if the original persisted message, and will not be rolled back, In this way, there will be two identical messages in the queue, and the system needs to support the de-weight.

RABBITMQ Series II (build Message Queuing)