Rabbitmq:vhost,exchanges, Queues,bindings and Channels

And rabbitmq The fate of this project is very strange, for a long time is only concerned about the source code, really is the model of Erlang open source project, and now to apply RABBITMQ in the project, from the new perspective, a new feeling. As if the old man changed the new clothes, although it is familiar but have never tasted the amorous feelings. RABBITMQ provides a set of mechanisms to handle the sending, receiving, fault tolerance and management of messages, and in the last article I mentioned an article about rabbits and warrens, which is a great introductory article, but it ignores a lot of details and I follow RABBITMQ in The action was re-combed, with notes on it, Memo.

exchanges, queues, and bindingsExchanges, queues, and bindings are three basic concepts, and their role is: Exchangesis where producers publish their messages, Queuesis where the messages end up and is received by consumers, and Bindingsis how the messages get routed from the exchange to particular queues. Here we use a simple mind map to organize the above concepts: The above also mentions a concept of vhost, Vhost is to organize the concept of exchanges, queues, and bindings, from which we begin to speak: VHostVhosts is also a basic concept of AMQP, connected to RABBITMQ by default there is a vhost called "/" is available, local debugging can be directly used when the default vhost. This "/" Access can use the guest username (password guest) Access. You can use the Rabbitmqctl tool to modify the permissions and passwords for this account, which must be a concern in a production environment.     For security and portability reasons, exchange within a vhost cannot bind to other vhost. The vhost can be planned according to the business function group, where the Vhost is created in a clustered environment as long as the vhost is created on a node within the entire cluster. Vhost and permissions are not created through the AMQP protocol, and are created and managed using Rabbitmqctl in RABBITMQ. How to create a vhostVhost and permission (permission) information is not created by AMQP but is added and managed through the Rabbitmqctl tool. after Vhost, let's take a look at the heavy news: message   MessageThe message consists of two parts: payload and label. "Payload" is the actual data to be transferred, as for the format of the data RABBITMQ does not care, "label" describes payload, including Exchange name and optional topic Tag. Once the message is in the consumer there is only payload part, and the label part is not brought here.     RABBITMQ doesn't tell you who sent the message. It's like you got a letter but the envelope is blank. Of course, you want to know who sent or have a way, in the message content contains the sender's information can be. The concept of consumer and producer for messages is that sending and receiving do not correspond to client and server. By channel we can create many parallel transport TCP links that are no longer a bottleneck, We can think of RABBITMQ as an application-level router. How consumer messages are receivedConsumer there are two ways to receive messages: Basic.consumeThe subscription queue. The channel will go into receive mode until you unsubscribe. Subscription mode consumer when the previous message processing is complete (ACK or deny), the new message is actively received. If the message arrives at the queue, it wants to be processed as soon as possible. You should also use the Basic.consume command. In another case, we don't have to keep the subscription, as long as we use the Basic.get command to proactively get the message. After the current message processing is complete, continue to get the message to take the initiative basic.get do not " Using Basic.ge "t as another form of basic.consume in a loop, as this approach has an additional cost compared to Basic.consume: Basic.get essentially is to subscribe to the queue to retrieve a message after the unsubscribe. Basic.consume is usually used when the consumer throughput is large. What if there's no consumer?If the message is not consumer, it will stay in the queue honestly. multiple consumer subscribe to the same queueAs long as consumer subscribes to the queue, the message is sent to the consumer. Our question is, how is the message in the queue distributed in this case? If a rabbit queue has multiple consumer, a message specific to the queue will only be sent to one of the consumer. Message ConfirmationAll received messages require a response message (ACK) to be sent. There are two ways in which the consumer uses Basic.ack to explicitly send an ACK, and one is to specify Auto_ack as true when subscribing to a queue.   As soon as the news arrived consumer there RABBITMQ would think the message had been ACK. Note that there is no relationship between the response and the sender of the message, the ACK is just consumer to RABBITMQ to confirm that the message has been correctly received, RABBITMQ can safely remove the message, that's all. What if I don't respond correctly?If consumer has received a message and has not sent an ACK to RABBITMQ, RABBITMQ will assume that the message is not delivered successfully and will be re-posted to another consumer. If your application is broken, you can set up a fallback program to continue processing the message. If the consumer itself has a problem with the logic and does not send ACK processing, RABBITMQ no longer sends a message to the consumer. RABBITMQ will think that this consumer has not finished processing the last message, No ability to continue receiving new messages. We can make good use of this mechanism, and if the processing process is quite complex, the application can delay sending an ACK until the processing is complete. This effectively controls the load on this side of the application without being hit by a lot of messages. Reject Message  Because the ACK response message has not been issued because the message is to be rejected, there are two options for rejecting the message here: 1.Consumer to disconnect RABBITMQ so RABBITMQ will re-queue the message,   Disposed of by other consumer. This method is supported in all versions of RABBITMQ. The disadvantage of this is that the disconnection increases the additional burden on the RABBITMQ, especially if the consumer exception occurs when every message fails to process properly.   2. RabbitMQ 2.0.0 can use the Basic.reject command and receive the command RabbitMQ will be re-posted to the other consumer. If you set Requeue to FALSE,RABBITMQ, the message is removed from the queue directly. In fact, there is a choice is to ignore this message directly and send an ACK, when you are clear until the message is abnormal, there will be no consumer can handle, you can discard the exception data. Why send a Basic.reject message instead of an ACK? Later versions of RABBITMQ may introduce the "Dead letter" queue, use Basic.reject and set Requeue to False if you want to use dead letter to do some articles. Message PersistenceThe persistence of the message requires that the delivery mode value be set to 2 when the message is delivered. Because the message is actually stored in the queue, "with Mao" logically, Message persistence also requires that Exchange and queue are also persisted. This is the three conditions that message persistence must meet. The cost of persistence is performance loss, disk IO is much slower than RAM (using SSDs can significantly improve the performance of message persistence), Persistence greatly reduces the messages that RABBITMQ can process per second. The performance gap between the two may be more than 10 times times. Message RecoveryConsumer the ACK message is returned after retrieving a message from the durable queue, RABBITMQ marks it for easy subsequent garbage collection. If a persistent message is not taken away by consumer, Exchange and queue (and bingding relationships) are automatically rebuilt after RABBITMQ restarts, and messages are re-entered into the corresponding queues,exchanges through persistent log rebuilds. with, Mao? And then we'll see where the message actually resides: Queue QueueQueues is the place where massage is located and waiting to be received, and messages are placed in a queue unless they are thrown into a black hole. Queue is well suited for load balancing, RABBITMQ can be rotated in several consumer (round-robin) . How to create a queueBoth consumer and producer can create a queue, and if consumer is created to avoid consumer subscribing to a nonexistent queue, there is a risk that the message has been delivered but consumer has not yet created the queue. Then the news will be thrown into the black hole, in other words the message is lost; a good way to avoid this is to try to create a queue producer and consumer.   If consumer cannot complete the creation of a new queue if it has subscribed to another queue, the previous subscription must be canceled to set the channel to transfer mode ("transmit") in order to create a new channel.   When creating a queue, it is usually necessary to specify a name, which is convenient for consumer subscriptions. Even if you do not specify rabbit it assigns a random name to it, which is useful when using a temporary anonymous queue to complete a RPC-OVER-AMQP call. There are also two very useful options when creating a queue: Exclusive-when set to True, your queue becomes private and can is only consumed by your app. This is useful if you need to limit a queue to only one consumer. Auto-delete-the queue is automatically deleted when the last consumer Unsubscribes.   If you want to create a temporary queue that uses only one consumer, you can use Auto-delete and Exclusive.consumer once disconnected to automatically delete the queue. What happens when you create a queue repeatedly? If the queue creation option is exactly the same, RABBITMQ directly returns success, and if the name is the same but the creation option is inconsistent, the creation failure is returned. If you want to check if the queue exists, You can set the passive option for the Queue.declare command to true: If the queue exists, it will return success if the queue does not exist and the creation logic will not be executed. How is a message routed from a dynamic to a different queue? That's what it looks like.   Bindings and Exchanges how messages are sent to the queue  How is the message sent to the queue? It's about AMQP. Bindings and Exchanges. The delivery of messages to the queue is done through exchange, and as in the case of live mail delivery, there are rules that bind the queue to exchange via routing key in RABBITMQ. This binding relationship is the BIND. Message sent to RABBITMQ will carry a routing key (even if it is an empty key), RABBITMQ will match routing key according to bindings, if the match success message is forwarded to the specified queue, If there is no match to the queue message it will be thrown into the black hole. How to send to multiple queuesis the message distributed to multiple queues? The AMQP protocol defines several different types of exchange:direct, Fanout, topic, and headers. Each of these implements a routing algorithm. The routed message of the header does not rely on routing key but rather matches the header portion of the AMQP message, which is the same as direct exchange mentioned below, but with much less performance and is rarely used in real-world scenarios. Direct ExchangeRouting key exact match before forwarding
fanout ExchangeIgnoring routing key, the message is broadcast directly to all bound queue
Topic ExchangeMatch to Routing key pattern Exchange PersistenceQueue creation and exchange are not persisted by default, and queue and exchange disappear after a node restart, specifically specifying the durable property for queue and exchange. consumer is directly creating a TCP link to rabbitmq? Here's the answer: ChannelWhether you want to publish a message or get a message, your application needs to connect to RABBITMQ over TCP. The channel is created after the application connects and passes permission authentication to execute the AMQP command. Channel is built on the actual TCP connection above the communication pipeline, The idea of introducing the channel concept instead of directly sending the AMQP command directly over a TCP link is a two-factor consideration: the creation of hundreds or thousands of TCP links, on the one hand, and the wasted TCP link On the one hand, the system bottleneck will soon be touched. The communication between multiple processes and RABBITMQ can be done on a TCP link after the channel has been introduced. We can make the TCP analogy an optical cable, then the channel is like a fiber in the fiber cable. References[1] rabbits and warrens http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/[2] rabbit and rabbit nest http// blog.ftofficer.com/2010/03/translation-rabbitmq-python-rabbits-and-warrens/------------break-up line--------------

Rabbitmq:vhost,exchanges, Queues,bindings and Channels