RABBITMQ Introduction 2-Understanding Message AMQP

Understanding Message AMQP Communication. Official explanation: http://www.rabbitmq.com/tutorials/amqp-concepts.html

Concept: Producer producer, consumer consumer, queue queues, exchanger exchange, routing key routing key, binding key binding keys.

Producer publishes a message, the message is placed in a queue by the exchanger propagation, and the consumer gets the message from the queue.

1. ConnectionFactory, connection, channel channels. ConnectionFactory is used to establish a connection, connection represents a TCP connection, and the channel is a virtual connection built on connection. Each channel is marked with a unique ID that publishes messages, binds, consumes messages, and all of these operations are done on the channel. Connection and channel relationships are similar to processes and threads.

Question: Can I subscribe to multiple queues on the same channel? Can producers and consumers use the same channel? Can the same channel send messages to multiple Exchange?

1. Messages include payload payload and tag label,payload is the data that needs to be transferred, can be anything (C # programming is a byte array), label is a description of the transfer data, such as routing key, persistent delivery Mode

Message persistence. If the exchange,queue,message is persistent, the message will be retained after the RABBITMQ reboot, and any link is not persisted and the message will not be restored. Persistence can reduce throughput by up to 10 times times (with SSD storage can be greatly mitigated) and work in a clustered environment is not good. If a node in the cluster crashes, the persistence queue on it disappears from the cluster, and all messages sent to these queues are lost before the node restarts. In contrast, non-persistent queues are rebuilt at other nodes after the node crashes, and messages can be sent to the rebuilt queue.

Message confirmation. Every message that a consumer receives must be confirmed. The consumer must explicitly send an acknowledgment to RABBITMQ via the AMQP basic.ack command, or set Auto_ack to True when subscribing to the queue. When Auto_ack is true, once a consumer receives a message, RABBITMQ automatically considers it to be confirmed. Only messages that have been confirmed will be removed from the queue. If the consumer receives the message, but does not confirm it, the message will enter the waiting confirmation state, and if the consumer's connection is disconnected, RABBITMQ will clear the status of the message and send it to the other consumers in the queue. If the consumer is not confirming, the message accumulates in the queue and does not time out. Consumers can also explicitly reject a message (Basic.reject command), when rejected if the Requeue parameter is true, the message will be sent back to the next subscription consumer, Requeue is false when the message is removed from the queue, the effect is similar to the send confirmation, the difference is 2.0 later version of the RABBITMQ will maintain the rejected message queue for subsequent investigation.

AMQP transaction transaction. Since the publication message does not return any information to the producer, how do you know if the server has saved persistent messages to the hard disk? The transaction is used to confirm that the sender's message has entered the queue (or is discarded). After the channel is set to Transaction mode, the message on this channel is sent serially, and only the previous message is confirmed to be successful before it is executed until the transaction is committed, ending the transaction mode of the channel. Transactions can significantly reduce the throughput of RABBITMQ (2~10 times).

Sender acknowledgement mode. This is the concept of RABBITMQ, which is not part of AMQP. Functions like the AMQP transaction, but does not require serial, greatly improves throughput. How to use: Set the Channel to confirm mode and only re-create the channel to turn off the setting. Messages sent on all channels are assigned a unique ID (starting at 1), and once the message is delivered successfully, the channel sends a confirmation to the producer. The producer receives the acknowledgment message of the channel through a callback (if the message is lost, it receives nack), and the producer can continue to send the message. Because there is no transactional message rollback, the sender confirms that the mode is lighter and the impact on the RABBITMQ server is negligible.

We have no way to get this ID of the channel assignment (Basic_publish does not return the ID information), then how to confirm that the ID in the channel acknowledgement message specifically refers to which message? The method is that the sender maintains the relationship between the message and the ID itself. A channel is generally used by only one thread, the ID starts from 1, increments by 1 each time, the sender can fully calculate the ID of the message.

1. Queue. A queue is the only place where messages are stored, and a message is routed either into the queue or discarded.

Messages in the RABBITMQ can only be stored in a queue, the producer (p in) produces the message and is eventually delivered to the queue, and the consumer (c) can get the message from the queue and consume it.

Multiple consumers can subscribe to the same queue, and messages in the queue are apportioned to multiple consumers according to Round-robin, rather than every consumer receiving all the messages.

From

Prefetch count. When a consumer subscribes to a message from a queue, RABBITMQ pushes all the messages in the queue to the consumer and waits for confirmation. By setting prefetch count, you can limit the number of messages sent to consumers before the message is confirmed. Setting this parameter can help with load balancing when there are multiple consumers subscribing to a queue. Note that the subscription mentioned here is a continuous subscription, not the one-time subscription through Basic.get.

Create a queue. Both producers and consumers can create queues using Queue.declare, and if a consumer subscribes to another queue on the same channel, it is no longer possible to create a queue. When you create a queue without specifying the name of the queue, RABBITMQ assigns a random name and returns in the results of the queue.declare. Create queue if it already exists, as long as the declaration parameter is exactly the same as the existing queue, RABBITMQ does nothing, the creation process returns successfully, and throws an exception if the argument does not match. If you want to check whether the queue exists, set the parameter passive to true if the queue exists, or return an error if the creation is successful.

Queue properties: Exclusive, if true, only your program can consume the queue. Auto-delete, if true, the queue is automatically deleted when the last consumer cancels the subscription.

1. Exchange. The generator sends the message to Exchange,exchange based on the message's routing key, routing the message to the appropriate queue. Different exchanger types Exchange type offers different routing scenarios, with Exchange Type 4: Direct,fanout,topic and headers.
   1. Direct The routing key of the message needs to match the binding key exactly.

When the producer (P) sends a message rotuing key=booking, the Queue1 and Queue2 are found to be compliant, the message is sent to both queues, and if the message is sent in rotuing key=create or rotuing key=confirm Messages are only pushed to the Queue2 queue, and other routing key messages will be discarded.

Note RABBITMQ has a default Exchange, the type is direct, there is no way to bind a queue to this exchange, but by specifying routing key, you can send a message to a queue with the same name.

1. Fanout. This type of exchange sends a message to all bindings on the above queue,routing key and the binding key does not work.

Producer (P) Production message 1 pushes message 1 to Exchange,exchange to push the message to all bind it to the queue, and the last two consumers will receive a message.

1. Topic The Binding key can use * and # to routing key for fuzzy matching, * denotes a word, #匹配0或多个单词, a word is "." section of the Division. The part of the point segment can be empty, such as bindingkey=*.* can match Routingkey is "." message, but bindingkey= "*" Cannot match Routingkey is empty. It is easy to understand that the routingkey is used in accordance with the Stringsplit method first. Splits, preserves white space characters, * represents a position after the split, #表示匹配0 ... n positions. The remaining characters need to be matched exactly.
   • Would "*" binding catch a message sent with an empty routing key? No
   • Would "#.*" catch a message with a string ":" As a key? Would it catch a message with a single word key? Will
   • How different was "a.*.#" from "a.#"? The former routingkey to have "a", the latter as long as there is "a" can match.

1. Point number ". Each segment of the delimited string is called a word, such as "Quick.orange.rabbit" contains 3 words quick,orange,rabbit.
2. * denotes a word, #表示0或多个单词.
3. The binding key uses "*" and "#" to blur the match routing key. The "*" or "#" in routing key is treated as a normal character.

When the producer sends the message routing KEY=F.C.E, it is only routed to Queue1, if routing key=a.c.e is routed to Queue1 and Queue2 at this time, if routing key=a.f.b, This will only send a message to Queue2.

1. Headers The headers switch allows you to match the header of the AMQP message instead of the routing key, but in addition to the direct switch, the performance is much worse, so it's not very practical and almost never used. A set of key-value pairs can be provided at bind time, and if the header of the message (also a set of key-value pairs) and its exact match, the message is routed to the queue.

1. Vhost Virtual host. RABBITMQ can create multiple vhost, each vhost is essentially a mini version of the RABBITMQ server, has its own exchange,queue, and the authority mechanism, similar to the virtual machine to the physical server, Vhost provides the logical separation of instances, Differentiate between RABBITMQ and many customers, and avoid queue and exchange naming conflicts. The default vhost is "/" and you can manage vhost through the Rabbitmqctl tool.
   1. Rabbitmqctl add_vhost Vhostname. Create Vhost
   2. Rabbitmqctl delete_vhost Vhostname. Delete Vhost
   3. Rabbitmqctl List_vhost. List all Vhost

RABBITMQ Introduction 2-Understanding Message AMQP