Basic concepts of RabbitMQ and rabbitmq

Basic concepts of RabbitMQ and rabbitmq

Go to: http://blog.csdn.net/whycold/article/details/41119807

About RabbitMQ

AMQP (Advanced Message Queuing Protocol) is an open standard for application layer protocols and is designed for Message-oriented middleware. Message-oriented middleware is mainly used for decoupling between components. message senders do not need to know the existence of message users.
AMQP features message-oriented, queue-oriented, routing (including point-to-point and publish/subscribe), reliability, and security.
RabbitMQ is an open-source AMQP implementation. The server side is written in Erlang and supports multiple clients, such as Python, Ruby, and ,. NET, Java, JMS, C, PHP, ActionScript, XMPP, STOMP, etc. AJAX is supported. It is used to store and forward messages in distributed systems, and has good performance in terms of ease of use, scalability, and high availability.

ConnectionFactory, Connection, Channel

ConnectionFactory, Connection, and Channel are the most basic objects in the APIS provided by RabbitMQ. Connection is the socket link of RabbitMQ, which encapsulates some logic related to the socket protocol. ConnectionFactory is the manufacturing factory of Connection.
Channel is the most important interface for us to deal with RabbitMQ. Most business operations are completed in the Channel interface, including defining Queue, defining Exchange, binding Queue and Exchange, and publishing messages.

Queue

A Queue is an internal object of RabbitMQ. It is used to store messages and is represented.

Messages in RabbitMQ can only be stored in the Queue. The producer (P) produces messages and finally delivers them to the Queue. The consumer (C) can obtain and consume messages from the Queue.

Multiple consumers can subscribe to the same Queue.Average shareProcess multiple consumers, rather than receiving and processing all messages from each consumer.

Message acknowledgment

In actual applications, messages in the Queue may be received by the consumer, but the message goes down (or in case of other exceptions) if the processing is not completed. In this case, messages may be lost. To avoid this situation, we can askThe consumer sends a receipt to RabbitMQ after the message is consumed., RabbitMQ receives the Message acknowledgment before removing the Message from the Queue;

If RabbitMQ does not receive a receipt and detects that the consumer's RabbitMQ connection is disconnected, RabbitMQ sends the message to other consumers (if multiple consumers exist) for processing.

The concept of timeout does not exist here. If a consumer processes a message for a long time, the message will not be sent to other consumers unless its RabbitMQ connection is disconnected.
If our developers forget to send the receipt to RabbitMQ after processing the business logic, this will lead to a serious bug-more and more messages will be accumulated in the Queue; after the consumer restarts, the messages will be repeatedly consumed and the business logic will be repeated...

In additionPub messageThere is no ack.

Message durability

If we want to avoid Message loss even when the RabbitMQ service is restarted, we can set both Queue and Message as durable ), this ensures that our RabbitMQ messages will not be lost in most cases. But it still cannot solve the issue of low probability loss (for example, the RabbitMQ server has received the message from the producer, but the RabbitMQ server has no time to persist the message ), if we need to manage such small probability events, we need to use transactions. As this is only a brief introduction to RabbitMQ, we will not explain the related transactions of RabbitMQ.

Prefetch count

As mentioned above, if multiple consumers subscribe to messages in the same Queue at the same time, messages in the Queue will be shared to multiple consumers. At this time, if the processing time of each message is different, it may cause some consumers to stay busy, while others will soon finish their work and remain idle. We can set prefetchCount to limit the number of messages each Queue sends to each consumer. For example, if prefetchCount is set to 1, Queue sends a message each time to each consumer; after the consumer completes processing the message, the Queue will send a message to the consumer.

 

Exchange

In the previous section, we can see that the producer delivers the message to the Queue. In fact, this will never happen in RabbitMQ. Actually, the producer sends messages to Exchange (X in the switch), and Exchange routes messages to one or more Queue (or discard messages ).

Routing key

When the producer sends a message to Exchange, it usually specifies a routing key to specify the routing rule for the message, this routing key must be used together with Exchange Type and binding key to take effect.
When the Exchange Type and binding key are fixed (in normal use, the content is usually fixed and configured), the producer sends a message to the Exchange, you can specify the routing key to determine the message flow direction.
RabbitMQ sets the length limit of 255 bytes for the routing key.

Binding

In RabbitMQ, Exchange and Queue are associated through Binding, so RabbitMQ knows how to route messages to the specified Queue correctly.

Binding key

When Binding Exchange and Queue, a binding key is usually specified. When a consumer sends a message to Exchange, a routing key is usually specified; when the binding key matches the routing key, the message is routed to the corresponding Queue. This section describes the actual examples in Exchange Types.
When Binding multiple Queue to the same Exchange, these bindings allow the same binding key.
Binding key does not take effect in all cases. It depends on Exchange Type. For example, fanout Type Exchange ignores binding key, instead, the message is routed to all the Queue bound to the Exchange.

Exchange Types

RabbitMQ commonly uses four types of Exchange types: fanout, direct, topic, and headers (the AMQP specification also mentions two types of Exchange types: system and custom, which are not described here ), the following is an introduction.

Fanout

Fanout type Exchange routing rules are very simple. It routes all messages sent to the Exchange to all the Queue bound to it.

All messages sent by the producer (P) to Exchange (X) are routed to two Queue in the figure and eventually consumed by two consumers (C1 and C2.

Direct

Direct Exchange routing rules are also very simple. They route messages to the Queue where the binding key and the routing key exactly match.

Take the configuration as an example, we send a message to Exchange with routingKey = "error", the message will be routed to Queue1 (amqp. gen-S9b ..., This is the name of the Queue automatically generated by RabbitMQ) and Queue2 (amqp. gen-Agl ...); If we use routingKey = "info" or routingKey = "warning" to send messages, the messages will only be routed to Queue2. If we send messages with other routingkeys, the messages will not be routed to these two Queue.

Topic

As mentioned above, direct Exchange routing rules fully match binding key and routing key, but this strict matching method cannot meet actual business requirements in many cases. Exchange of the topic type is extended in the matching rules. It is similar to the Exchage of the direct type and routes messages to the Queue that matches the binding key and the routing key, however, the matching rules here are somewhat different, and the conventions are as follows:

• Routing key is a period ". "separator string (we will be separated by the period". "Each separate string is called a word), such as" stock. usd. nyse "," nyse. vmw and quick. orange. rabbit"
• The binding key and the routing key are also strings separated by periods (.).
• There can be two special characters "*" and "#" in the binding key for Fuzzy Matching. "*" is used to match a word, "#" is used to match multiple words (it can be zero words)

Take the configuration in as an example, routingKey = "quick. orange. rabbit messages are routed to Q1 and Q2 at the same time, routingKey = "lazy. orange. the fox message is routed to Q1, routingKey = "lazy. brown. the fox message is routed to Q2, routingKey = "lazy. pink. rabbit messages are routed to Q2 (only once delivered to Q2, although the two bindingkeys of this routingKey and Q2 match); routingKey = "quick. brown. fox ", routingKey =" orange ", routingKey =" quick. orange. male. rabbit messages will be discarded because they do not match any bindingKey.

Headers

The headers type Exchange does not rely on the matching rules of the routing key and binding key to route messages. Instead, it matches the headers attribute in the sent message content.
Specify a set of key-value pairs when binding Queue and Exchange. When a message is sent to Exchange, RabbitMQ obtains the headers (also in the form of a key-value pair) of the message ), compare whether the key-value pairs fully match the key-value pairs specified when the Queue is bound to Exchange. If the key-value pairs fully match, the messages are routed to the Queue; otherwise, the messages are not routed to the Queue.
This type of Exchange has never been used (but it should also be useful), so we will not introduce it.

RPC

MQ itself is based on asynchronous message processing. All the producers (P) in the preceding example do not know the consumer (C) after messages are sent to RabbitMQ) processing is successful or failed (even if there is no consumer to process this message ).
However, in actual application scenarios, we may need some synchronous processing. We need to wait for the server to process my messages before proceeding to the next step. This is equivalent to RPC (Remote Procedure Call, Remote process Call ). RPC is also supported in RabbitMQ.

The RPC implementation mechanism in RabbitMQ is as follows:

• When a client sends a request (Message), properties in message 14 are defined in MessageProperties, which are sent along with the message) set two values: replyTo (a Queue name, used to tell the server to send the notification message to this Queue after processing is completed) and correlationId (ID of this request, after the server completes processing, it needs to return this attribute. The client will know which request has been successfully executed or failed to execute according to this id)
• The server receives and processes the message.
• After the server finishes processing the message, it will generate a Response Message to the specified Queue of replyTo, with the correlationId attribute
• The client has subscribed to the Queue specified by replyTo. After receiving the server response message, it analyzes which request is executed based on the correlationId attribute and carries out subsequent Business Processing Based on the execution result.
•