Janet previous chapter "Janet: Look at the Big Data era of IT Architecture (1) Industry message Queue comparison", roughly speaking, the current message queue of several common products of the pros and cons of the comparison, the next few chapters will be elaborated in detail, this chapter introduces RABBITMQ, OK, nonsense less, formally started:
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. FirstTalk 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 Concepts 1The RabbitMQ structure diagram is as follows: 2) highlights some of the more important basic concepts
①query: (queue)A Query (queue) is an internal object of RABBITMQ that stores information, with (1-3-2-1) representation
(
1-3-2-1) RThe information in the ABBITMQ can only be stored in query, the producer (p) Producer messages and eventually delivered to query, and the consumer (c in 1-3-2-2) can get messages from query and consume them.(
1-3-2-2)Multiple consumers can subscribe to the same query, when the message in query is evenly distributed to multiple consumers, not every consumer receives all the messages and processes them.
②
Message acknowlegment: (Receipt of messages)In the actual application, the consumer may receive the message in the query, but did not finish the situation of achievement outage, in this case, may lead to the loss of information, in order to avoid this situation, we can ask consumers to send a receipt after consuming the message to RABBITMQ, RABBITMQ the message receipt (message acknowledge) is received before it is removed from query. 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, and if the developer processes the business completion logic and forgets to send receipts to RABBITMQ, this will cause serious bugs---more and more messages will accumulate in query, and consumer restarts will repeat the consumption of these messages and repeat the business logic.
③message Durability: (Message persistence)If we want to not lose the message even when the RABBITMQ is restarted, we set the query and the message to be persisted (durability) so that we can guarantee that our RABBITMQ messages will not be lost in most cases. But it's still not going to solve the small probability of the loss event (
For example, the RABBITMQ server has received the message from the producer, but when the message has not come and persisted, the RABBITMQ server is powered off or down, if we need to manage this small probability event, Then we need to use the business 。
④prefetch count (prefetch number)We mentioned earlier that if more than one consumer subscribes to a message in the same query, the message in query is 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 prefetch count=1, and query sends a message to each consumer every time, and when the consumer finishes processing the message, query sends a message to the consumer.⑤
Exchange (EXCHANGER)
In the previous section we saw that the producer posted the message into query, which in fact was not possible in RABBITMQ, in fact, the producer sent the message to Exchange (exchanger, in X), and Exchange routed the message to one or more query or dropped. EWhat logic does Xchange follow to route messages to query? 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 query by binding in RabbitMQ so that RabbitMQ knows how to correctly route the message to the specified query.⑧exchange Type (Replacement)RABBITMQ Common Exchange Tpye have fanout, direct, top, headers four kinds⑨fanout (column) The fanout type of Exchange routing rule is very simple, and it routes all messages sent to that exchange to all of 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
