Foreword:
MQ what is it? What is the queue, MQ we can understand it as a message queue, and we can understand the queue as a pipeline. Message passing through pipes.
Scenes:
1. In fact, when we were on Double 11, when we sold a lot of spikes and snapped up products in the early morning, and then went to checkout, we would find that the interface would remind us, let us wait a moment, and some friendly pictures and text reminders. It is not like the era of a few years ago, when the page is stuck, errors are reported, etc. to be presented to users.
In this business scenario, we can use the queue mechanism to deal with it, because the settlement can only reach so much at the same time.
2. The same is true for shopping in our usual supermarket. When we check out, we will not rush into the cashier like a swarm, but queue up to settle. This is also a queue mechanism.
Yes, it's the queue. One by one processing, can not cut the queue.
Introduction to RabbitMQ
AMQP, the 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, queuing, 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 language, supports a variety of clients, such as: Python, Ruby, .NET, Java, JMS, C, PHP, ActionScript, XMPP, STOMP, etc., supports AJAX. It is used to store and forward messages in distributed systems, and it performs well in terms of ease of use, scalability, and high availability. The following will focus on some basic concepts in RabbitMQ. Understanding these concepts is the basis for using RabbitMQ well.
ConnectionFactory、Connection、Channel
ConnectionFactory, Connection, and Channel are the most basic objects in the API 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 we deal with RabbitMQ. Most of our business operations are completed in the Channel interface, including defining Queue, defining Exchange, binding Queue and Exchange, publishing messages, etc.
Queue
Queue (queue) is an internal object of RabbitMQ, used to store messages, represented by the following figure.
The messages in RabbitMQ can only be stored in the Queue. The producer (P in the figure below) produces the message and finally delivers it to the Queue. The consumer (C in the figure below) can get the message from the Queue and consume it.
Multiple consumers can subscribe to the same Queue. At this time, the messages in the Queue will be evenly distributed to multiple consumers for processing, instead of each consumer receiving all the messages and processing them. 
Message acknowledgment
In practical applications, it may happen that the consumer receives the message in the Queue, but fails to complete the processing (or has other accidents). In this case, the message may be lost. In order to avoid this situation, we can ask the consumer to send a receipt to RabbitMQ after consuming the message, and RabbitMQ will remove the message from the Queue after receiving the message acknowledgment; if RabbitMQ does not receive the receipt and Detecting that the consumer's RabbitMQ connection is disconnected, RabbitMQ will send the message to other consumers (if there are multiple consumers) for processing. There is no timeout concept here, and a consumer processing a message for a long time will not cause the message to be sent to other consumers unless its RabbitMQ connection is disconnected. Another problem will arise here. If our developers forget to send a receipt to RabbitMQ after processing the business logic, this will lead to serious bugs - more and more messages will accumulate in the Queue; Consume these messages repeatedly and execute business logic repeatedly...
In addition, the pub message has no ack.
Message durability
If we hope that the message will not be lost even when the RabbitMQ service is restarted, we can set both Queue and Message to be durable, which can ensure that our RabbitMQ messages will not be lost in most cases . But it still can't solve the occurrence of small probability loss events (for example, the RabbitMQ server has received the message from the producer, but the RabbitMQ server is powered off before it has time to persist the message), if we need to deal with such small probability events Managed, then we need to use affairs. Since this is only a brief introduction to RabbitMQ, RabbitMQ related transactions will not be explained here.
Prefetch count
Earlier we mentioned that if multiple consumers subscribe to messages in the same Queue at the same time, the messages in the Queue will be shared among multiple consumers. At this time, if the processing time of each message is different, it may cause some consumers to be busy all the time, while other consumers quickly finish the work at hand and remain idle. We can limit the number of messages that the Queue sends to each consumer each time by setting prefetchCount. For example, if we set prefetchCount=1, the Queue sends a message to each consumer at a time; after the consumer processes the message, the Queue will Send another message to the consumer.
Exchange
In the previous section we saw that the producer posts messages to the Queue, which in fact never happens in RabbitMQ. The actual situation is that the producer sends the message to the Exchange (exchange, X in the figure below), and the Exchange routes the message to one or more Queues (or discards). 
According to what logic does Exchange route messages to Queue? This will be introduced in the Binding section. There are four types of Exchange in RabbitMQ, and different types have different routing strategies, which will be introduced in the Exchange Types section.
routing key
When a producer sends a message to Exchange, it usually specifies a routing key to specify the routing rules for the message, and this routing key needs to be used in conjunction with the Exchange Type and the binding key to take effect. In the case where the Exchange Type and the binding key are fixed (in normal use, these contents are generally fixedly configured), our producer can determine where the message flows by specifying the routing key when sending a message to the Exchange. The length limit set by RabbitMQ for the routing key is 255 bytes.
Binding
In RabbitMQ, Exchange is associated with Queue through Binding, so that RabbitMQ knows how to correctly route messages to the specified Queue. 
Binding key
When binding Exchange and Queue, a binding key is generally specified; when a consumer sends a message to Exchange, a routing key is generally specified; when the binding key matches the routing key, the message will be routed to the corresponding Queue. This will be illustrated with practical examples in the Exchange Types chapter. When binding multiple Queues to the same Exchange, these Bindings allow the same binding key to be used. The binding key does not take effect in all cases. It depends on the Exchange Type. For example, a fanout type of Exchange will ignore the binding key and route messages to all Queues bound to the Exchange.
Exchange Types
The commonly used Exchange Types in RabbitMQ are fanout, direct, topic, and headers (there are also two Exchange Types mentioned in the AMQP specification, which are system and custom, which will not be described here).
fanout
The exchange routing rule of the fanout type is very simple, it will route all messages sent to the exchange to all the Queues bound to it. 
In the above figure, all messages sent by the producer (P) to the Exchange (X) will be routed to the two Queues in the figure, and eventually consumed by the two consumers (C1 and C2).
direct
The direct type Exchange routing rule is also very simple, it will route the message to those Queues whose binding key exactly matches the routing key. 
As an example of the configuration in the above figure, we send a message to Exchange with routingKey=”error”, and the message will be routed to Queue1 (amqp.gen-S9b…, which 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 the message with other routingKey, the message will not be routed into these two Queues.
topic
As mentioned earlier, the direct-type Exchange routing rule completely matches the binding key and routing key, but this strict matching method cannot meet actual business needs in many cases. The topic-type Exchange has been extended on the matching rules. It is similar to the direct-type Exchage. It also routes messages to the Queue whose binding key matches the routing key. However, the matching rules here are somewhat different. It agrees:
- The routing key is a string separated by a period ". " (we call each independent string separated by a period ". " a word), such as "stock.usd.nyse", "nyse. vmw", "quick.orange.rabbit"
- The binding key, like the routing key, is also a string separated by a period "."
- There can be two special characters "*" and "#" in the binding key, which are used for fuzzy matching, where "*" is used to match one word, and "#" is used to match multiple words (can be zero)
Take the configuration in the above figure as an example, the message with routingKey=”quick.orange.rabbit” will be routed to Q1 and Q2 at the same time, and the message with routingKey=”lazy.orange.fox” will be routed to Q1 and Q2, routingKey=”lazy. The message of brown.fox" will be routed to Q2, and the message of routingKey=”lazy.pink.rabbit” will be routed to Q2 (it will only be delivered to Q2 once, although this routingKey matches both bindingKeys of Q2); 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 of Exchange does not rely on the matching rule between the routing key and the binding key to route messages, but matches according to the headers attribute in the content of the sent message. Specify a set of key-value pairs when binding Queue and Exchange; when a message is sent to Exchange, RabbitMQ will get the headers of the message (also in the form of a key-value pair), and compare whether the key-value pair exactly matches Queue and The key-value pair specified when the Exchange is bound; if it matches exactly, the message will be routed to the Queue, otherwise it will not be routed to the Queue. This type of Exchange has not been used (but it should be very useful), so I will not introduce it.
RPC
MQ itself is based on asynchronous message processing. In the previous example, all producers (P) will not know the success or failure of the consumer (C) processing after sending the message to RabbitMQ (even whether there is a consumer to process the message). Do not know at all). But in the actual application scenario, we may need some synchronous processing, and we need to wait for the server to finish processing my message before proceeding to the next step. This is equivalent to RPC (Remote Procedure Call). RPC is also supported in RabbitMQ. 
The mechanism implemented in RabbitMQRPC is:
- When the client sends a request (message),
MessagePropertiesit sets two values (aAMQPname to tell the server to notify when processing is complete ) My message is sent to this ) and (the identification number of this request, the server needs to return this attribute after processing is completed, and the client will know which request was successfully executed or failed according to this id)propertiesreplyToQueueQueuecorrelationId - The server receives the message and processes it
- After the server has processed the message, it will generate a response message to the
replyTospecified oneQueuewithcorrelationIdattributes - The client has subscribed to
replyTothe specified one beforeQueue, and after receiving the response message from the server, itcorrelationIdanalyzes which request has been executed according to its attributes, and performs subsequent business processing according to the execution result.
Summarize
This article introduces the RabbitMQ concepts that I think are the most important, and RabbitMQ we can handle most of our asynchronous business by making full use of these functions provided.
RabbitMQ selection and comparison
1. From community activity
According to the current information on the Internet, RabbitMQ , , activeM and the ZeroMQ three RabbitMQ are the first choice.
2. Persistent message comparison
ZeroMq Not supported, ActiveMq and RabbitMq both supported. Persistent messages mainly refer to the mechanism that our machine hangs up in the event of force majeure and the message will not be lost.
3. Comprehensive technology implementation
Reliability, flexible routing, clustering, transactions, highly available queues, message ordering, issue tracking, visual management tools, plugin systems, and more.
RabbitMq / Kafka best, ActiveMq next, ZeroMq worst. Of course, ZeroMq you can do it, but you have to manually write the code to implement it, and the amount of code is not small. Especially in reliability: Durability, Delivery Confirmation, Publisher Confirmation, and High Availability.
4. High concurrency
Undoubtedly, the RabbitMQ highest, because its implementation language is a language with high concurrency and high availability by nature erlang .
5. Comparison of Concerns, RabbitMQ and Kafka
RabbitMqKafka More mature, RabbitMq is better than Kafka ( theoretically) in terms of availability, stability, and reliability.
In addition, Kafka the positioning of the log is mainly in the log, because Kafka the original intention of the design is to process the log, it can be regarded as an important component of a log (message) system, and it is highly targeted, so it is recommended to choose it if the business is concerned RabbitMq .
There is, Kafka the performance (throughput, TPS ) ratio is RabbitMq much higher.
The final summary of the selection:
If we already have the choice of Kafka or RabbitMq in our system , and it can fully meet the current business, it is recommended not to repeatedly add and build wheels.
You can choose one between Kafka and RabbitMq that suits your team and business, this is the most important. But there is no doubt that at this stage, there is no third option for comprehensive consideration.
The original text comes from: https://www.sojson.com/blog/48.html