First, the basic concept of a detailed introduction1. Introduction
Have you ever encountered two (multiple) systems that need to synchronize certain data through a timed task? Are you struggling with the problem of calling and communicating between different processes of heterogeneous systems? If so, congratulations, the messaging service makes it easy for you to solve these problems.
The Messaging service specializes in solving data exchange (message notification/communication) issues between multiple systems and heterogeneous systems, and you can also use it for inter-system service invocation (RPC). The RABBITMQ that this article will introduce is one of the most mainstream message middleware .
2, RABBITMQ introduction
RabbitMQ is a popular open source Message Queuing system, developed in Erlang language. RABBITMQ is the standard implementation of the AMQP (Advanced Message Queuing protocol). If you are unfamiliar with AMQP, it can be difficult to see RABBITMQ documents directly. First talk about
AMQP
AMQP, Advanced message Queuing Protocol, is an open standard for application-layer protocols designed for message-oriented middleware. Message middleware is mainly used for decoupling between components, the sender of the message does not need to know the existence of the message consumer, and vice versa.
The main features of AMQP are message-oriented, queue, routing (including point-to-point and publish/subscribe), reliability, and security.
RabbitMQ is an open source AMQP implementation that is written by the server side in Erlang and supports a variety of clients such as Python, Ruby,. NET, Java, JMS, C, PHP, ActionScript, XMPP, Stomp and so on, support Ajax. It is used to store and forward messages in distributed system, which is very good in ease of use, extensibility, high availability and so on.
The following will focus on some of the basic concepts in RABBITMQ, and understand these concepts as the basis for using good RABBITMQ. 3. Basic Concepts1) The RabbitMQ structure diagram is as follows:2) Highlight some of the more important basic concepts
①quque: (queue)Quque (queue) is an internal object of RABBITMQ that stores information and has (1-3-2-1) representation
(
1-3-2-1) the information in the RABBITMQ can only be stored in Quque, producer (p) Producer messages and eventually delivered to Quque, and consumers (c in 1-3-2-2) can get messages from quque and consume them. (
1-3-2-2) multiple consumers can subscribe to the same quque, when messages in Quque are distributed evenly across multiple consumers, rather than every consumer receiving all messages and processing.
② message
acknowlegment: (Message receipt) in the actual application, the consumer receives the message in the Quque, but does not finish the situation which the achievement goes down, in this case, may cause the information to lose, in order to avoid this situation, we may ask the consumer to send a receipt to the RABBITMQ after consumes the message, RABBITMQ the message receipt (message acknowledge) is received before it is removed from Quque. If RABBITMQ does not receive a receipt and detects that the consumer's RABBITMQ link is broken, RABBITMQ will send the message to other consumers (in case there are multiple consumers) for processing, there is no concept of timeout here, No matter how long a consumer consumes time, it will not cause the message to be sent to other consumers unless its RABBITMQ connection is broken;
Note: There is a problem here, if the developer processes the business completion logic, forget to send receipts to RABBITMQ, which will lead to serious bugs---the quque will accumulate more and more messages, consumer restart will repeatedly consume these messages and repeat the business logic.
③message Durability: (Message persistence)if we want to not lose the message even if the RABBITMQ is restarted, then we set the Quque and the message to be persisted (durability), so that we can guarantee that our RABBITMQ messages will not be lost in most cases. But still can't solve the small probability of the loss of events (
such as the RABBITMQ server has received the message of the producer, but, has not come and persisted the message, the RABBITMQ server is powered off or down), If we need to manage this small probability event, then we need to use the transaction .
④prefetch count (prefetch number)we mentioned earlier that if more than one consumer subscribes to a message in the same quque, the message in Quque will be split to multiple consumers. At this point, if the processing time of each message is different, it is possible that some consumers have been busy, while others quickly finish the work on hand, and always idle. We can set the prefetch count=1, then quque send a message to each consumer each time, the consumer after processing this message quque will send a message to the consumer again. ⑤
Exchange (exchanger) In the previous section we saw that the producer posted the message to Quque, which in fact was not possible in RABBITMQ, in fact, that the producer sent the message to Exchange (exchanger, in X), Exchange routes messages to one or more quque or drops. What logic does exchange follow to route messages to Quque? This will be elaborated in the binding section. There are four types of exchange in RABBITMQ, different types have different routing policies, which will be elaborated in the Exchange Types section
⑥routing Key (Route key)when a producer sends a message to exchange, a routing key is typically specified to specify the routing rule, and the routing key needs to be used in conjunction with the Exchange Type and binding key to finally take effect. in the case where Exchange Tpye is fixed with the binding key (which is configured for normal use), our producer can specify the flow direction of the message by specifying routing key when sending the message to exchange. ⑦ binding
(BIND) Exchange is associated with quque by binding in RabbitMQ so that RabbitMQ knows how to correctly route messages to the specified quque.⑧exchange Type (Replacement)RABBITMQ Common Exchange Tpye have fanout, direct, top, headers four kinds⑨fanout (breakdown) The Fanout type of Exchange routing rule is simple, and it routes all messages sent to that Exchange to all the queues it binds to.
⑩direct (redirected)the direct type of Exchange routing rule is also simple, which routes messages to a queue whose binding key exactly matches the routing key.
As an example of configuration, we send a message to exchange with routingkey= "error", the message is routed to Queue1 (amqp.gen-s9b ..., This is the queue name automatically generated by RABBITMQ) and Queue2 (Amqp.gen-agl ... If we send a message with routingkey= "info" or routingkey= "warning", the message will only be routed to Queue2. If we send a message with another routingkey, the message is not routed to the two queue. ? Topic (Theme)
The preceding Exchange routing rules for the direct type are exactly the same as the binding key and routing key, but this strict matching method does not meet the actual business requirements in many cases. Topic type of exchange has been extended on matching rules, similar to the exchage of the direct type, and to the queue where the message is routed to the binding key that matches the routing key, but there are some differences in the matching rules, which contract:
- Routing key is a period number ". "Delimited string (we will be the period number".) "Each separated section of a separate string is called a word", such as "Stock.usd.nyse", "NYSE.VMW", "Quick.orange.rabbit"
- The binding key, like routing key, is also the period number ". "Delimited string
- There can be two special characters "*" and "#" in the binding key to make a fuzzy match, where "*" is used to match a word, "#" is used to match multiple words (can be 0) "
As an example of configuration in, routingkey= "Quick.orange.rabbit" messages are routed to Q1 and q2,routingkey= "Lazy.orange.fox" messages are routed to q1,routingkey= " Lazy.brown.fox "messages that are routed to q2,routingkey=" Lazy.pink.rabbit "will be routed to Q2 (only sent to Q2 once, although this routingkey matches the Q2 of two Bindingkey) , routingkey= "Quick.brown.fox", routingkey= "Orange", routingkey= "quick.orange.male.rabbit" messages will be discarded, Because they don't match any bindingkey. ? HeadersThe headers type of exchange does not rely on the matching rules of routing key and the binding key to route messages, but rather matches the headers attributes in the message content sent.
Specifies a set of key-value pairs when a queue is bound to exchange, and when a message is sent to Exchange, RABBITMQ takes the headers of the message (which is also a key-value pair). Compares whether the key-value pair exactly matches the key-value pair specified by the queue with Exchange bindings, or if the message is routed to the queue in an exact match, otherwise it is not routed to the queue.
This type of exchange is not used (but should also be useful), so don't introduce it. ? RPC (Remote procedure Call)MQ itself is asynchronous-based message processing, and all the Producers (P) in the previous example send the message to RABBITMQ without knowing that the consumer (C) is processing success or failure (even if there is no consumer to handle the message).
However, in the actual application scenario, we will probably need some synchronous processing and need to wait for the server to finish processing my message before proceeding to the next step. This is equivalent to the RPC (remote Procedure call, which is called remotely). RPC is also supported in RABBITMQ.
The mechanism for implementing RPC in RABBITMQ is:
- When a client sends a request (message), the properties of the message (messageproperties, which are defined in the AMQP protocol in the 14 properties, which are sent along with the message) set two values ReplyTo (a queue name, Used to tell the server to send a message to the queue after processing is complete, and correlationid (the identification number of this request, the server will need to return this property after processing is completed, the client is based on this ID to know which request was executed successfully or failed to execute)
- The server receives the message and processes
- After the server finishes processing the message, a reply message is generated to the queue specified by ReplyTo with the Correlationid property
- After the client has subscribed to the queue specified by ReplyTo, and receives a reply message from the server, it analyzes which request was executed based on the Correlationid property, and performs subsequent business processing based on the result of the execution.
second, MQ featuresthird, the use of the sceneIv. meaningFive, installationhttp://blog.csdn.net/sun305355024sun/article/details/41918315Vi. ClientSeven, the service side
Janet: Looking at the IT architecture in the Big Data Era (2) rabbitmq-basic concept of Message Queuing detailed introduction
