RABBITMQ Message Queuing noun interpretation [go]

As can be seen from the AMQP protocol, MessageQueue, Exchange, and binding form the core of the AMQP protocol, and we'll take a holistic look at how these three major components can be leveraged from the perspective of application use Rabbit MQ constructs message queues and considerations for using them.

1. Declaration MessageQueue

In Rabbit MQ, whether a producer sends a message or a consumer accepts 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, we need to make clear:

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

b) After the message is accepted 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 is necessary for both producers and consumers to try to establish a message queue before sending or receiving the message. Here's one thing to be clear, if the client tries to establish a message queue that already exists, Rabbit MQ will not do anything and return the client to build successfully.

If a consumer is listening to a queue's message in one channel, Rabbit MQ does not allow the consumer to declare the other queue in the same channels. Rabbit MQ, a queue can be declared with the Queue.declare command, and the following properties of the queue can be set:

A) 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, the exclusive queue will be automatically deleted once the connection is closed or the client exits. This queue applies to scenarios where only one client sends a read message.

b) 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.

c) Durable: persistence, this will be discussed later as a special chapter.

d) 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.

2. Producers send messages

In the AMQP model, Exchange is a critical component that accepts 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 Rabbit MQ, declaring an exchange requires three parameters: Exchangename,exchangetype and durable. Exchangename is the name of the exchange that needs to be specified when creating the binding and the producer pushes the message through publish. ExchangeType, which refers to the type of exchange, 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 this exchange, which is discussed in the Message Persistence section. Declaring a binding requires providing a queuename,exchangename and a bindingkey. Let's examine the different routing rules that different ExchangeType show.

When a producer sends a message, it needs to specify a Routingkey and Exchange,exchange after receiving the Routingkey, the ExchangeType will be judged:

A) in the case of the direct type, the Routingkey in the message is compared to the bindingkey in all the binding associated with the exchange, and if it is equal, it is sent to the queue corresponding to the binding.

b) In the case of a fanout type, a message is sent to all queues that have a binding defined by the exchange, which is actually a broadcast behavior.

c) If it is a topic type, the Routingkey and Bindingkey are matched according to the regular expression, and if the match succeeds, it is sent to the corresponding queue.

3. Consumer subscription messages

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 consume a queue first, 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. For example, there are queue queues, where Clienta and ClientB both consume the queue, Messagea arrives in the queue, is dispatched to the Clienta,clienta reply server to receive the response, and the server deletes Messagea Another message Messageb arrives in the queue, the server sends the message to CLIENTB according to the "cyclic push" principle, and then receives the CLIENTB confirmation, deletes the MESSAGEB, and waits for the next message, the server sends the message to Clienta again.

Here we can see that after the consumer receives the message, all need to send a confirmation command to the server, This is the call Basic.ack implementation that can be displayed in Handledelivery, or the Autoack property is true when consume a queue. This ACK is simply a notification that the server can safely delete the message instead of notifying the producer, unlike RPC. 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, it is also possible to have the message server delete the message directly and not retransmit it by means of an ACK.

4. Persistence:

RABBITMQ defaults to non-persistent 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 MessageQueue to true, you can make the queue and exchange persistent, but this does not make the messages in the queue persist, requiring the producer to set delivery mode to 2 when sending messages , only these 3 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 for ture queues to bind, otherwise at bind time, RABBITMQ will be thrown wrong. Persistence can have a significant impact on the performance of RABBITMQ, which can be reduced by more than 10 times times.

5. 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 () If the server crashes without committing, the message will not be received by the server. Of course Rabbit MQ also provides the Txrollback () command for rolling back a transaction.

6. Confirm mechanism:

Using transactions is a guarantee that only committed transactions will be executed by the server. But it also synchronizes the client with the messaging server, which deviates from the nature of Message Queuing decoupling. Rabbit MQ provides a more lightweight mechanism to ensure that a producer can perceive whether a 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 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. The producer will know that the message has been properly distributed. 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 a nack indicating that the message has been lost so that the producer can ensure that the message is not lost by re-sending the message. 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 whether 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.

Turn:

http://backend.blog.163.com/blog/static/202294126201322563245975/

RABBITMQ Message Queuing noun interpretation [go]