A message queue is an asynchronous cooperation mechanism between applications.

Scenarios using MQ:

Taking a common order system as an example, the business logic after a user clicks the [Place Order] button may include: deducting inventory, generating corresponding documents, sending red envelopes, and sending SMS notifications. In the early stage of business development, these logics may be put together and executed synchronously. With the development of the business, the number of orders increases, and the performance of system services needs to be improved. At this time, some operations that do not need to take effect immediately can be split and executed asynchronously, such as issuing red envelopes, Send SMS notifications, etc. In this scenario, MQ can be used to send a message to MQ after the main process of placing an order (such as deducting inventory and generating corresponding documents) to complete the main process quickly, while another separate thread pulls MQ messages (or MQ pushes messages), when it is found that there are messages such as red envelopes or text messages in MQ, the corresponding business logic is executed.

The above is the case for business decoupling. Other common scenarios include eventual consistency, broadcast, staggered flow control, and so on.

RabbitMQ is an open source implementation of AMQP developed in the Erlang language.

AMQP: Advanced Message Queue, Advanced Message Queuing Protocol. It is an open standard of the application layer protocol, designed for message-oriented middleware. Clients and message middleware based on this protocol can transfer messages, and are not limited by products, development languages, and other conditions.

Features:

Reliability
RabbitMQ uses some mechanisms to ensure reliability, such as persistence, transmission confirmation, and publishing confirmation.
Flexible Routing
routes messages through Exchange before they enter the queue. For typical routing functions, RabbitMQ already provides some built-in Exchange to implement. For more complex routing functions, multiple Exchanges can be bound together, and their own Exchanges can also be implemented through the plug-in mechanism.
Message clustering (Clustering)
Multiple RabbitMQ servers can form a cluster to form a logical Broker.
High Availability (Highly Available Queues)
queues can be mirrored on machines in the cluster, so that the queues are still available in the event of some node failure.
Multi-protocol
RabbitMQ supports a variety of message queue protocols, such as STOMP, MQTT, etc.
Many Clients
RabbitMQ supports almost all common languages, such as Java, .NET, Ruby, etc.
Management UI
RabbitMQ provides an easy-to-use user interface that enables users to monitor and manage many aspects of the message broker.
Tracing mechanism (Tracing)
If the message is abnormal, RabbitMQ provides a message tracking mechanism, the user can find out what happened.
Plugin System (Plugin System)
RabbitMQ provides many plugins to be extended in many ways, and you can also write your own plugins.

Message model:

A consumer subscribes to a queue. The producer (producer) creates the message, then publishes it to the queue (queue), and finally sends the message to the listening consumers.

Message
message, the message is anonymous, it consists of a message header and a message body. The message body is opaque, and the message header consists of a series of optional attributes, including routing-key (routing key), priority (priority relative to other messages), delivery-mode (indicating that the message may require persistent storage), etc.

The producer of Publisher
messages is also a client application that publishes messages to the Exchange.
An Exchange
exchange that receives messages sent by producers and routes them to queues in the server.
Binding
binding for the association between message queues and exchanges. A binding is a routing rule that connects the exchange and the message queue based on the routing key, so the exchange can be understood as a routing table composed of bindings.
Queue
message queue, used to hold messages until they are sent to consumers. It is the container for the message and the destination for the message. A message can be put into one or more queues. The message has been in the queue, waiting for the consumer to connect to the queue to take it away.
Connection
network connection, such as a TCP connection.
Channel
channel, an independent bidirectional data flow channel in a multiplexed connection. The channel is a virtual connection established in the real TCP connection. AMQP commands are sent through the channel. Whether it is publishing a message, subscribing to a queue or receiving a message, these actions are completed through the channel. Because establishing and destroying TCP is very expensive for the operating system, the concept of channel is introduced to reuse a TCP connection.
Consumer
The consumer of the message represents a client application that gets messages from the message queue.
Virtual Host
virtual host, representing a batch of exchanges, message queues and related objects. Virtual hosts are separate server domains that share the same authentication and encryption environment. Each vhost is essentially a mini version of the RabbitMQ server, with its own queues, exchanges, bindings and permission mechanisms. vhost is the basis of AMQP concept and must be specified when connecting. The default vhost of RabbitMQ is /.
Broker
represents the message queue server entity.

Message Routing in AMQP

The routing process of messages in AMQP is somewhat different from the JMS familiar to Java developers. AMQP adds the roles of Exchange and Binding. The producer publishes the message to the Exchange, the message finally arrives at the queue and is received by the consumer, and the Binding decides which queue the exchange's message should be sent to.

Exchange type

Exchange distributes messages according to different distribution strategies of different types. There are currently four types: direct, fanout, topic, and headers. The headers match the header of the AMQP message instead of the routing key. In addition, the headers exchange is exactly the same as the direct exchange, but the performance is much worse, and it is hardly used at present, so let’s look at the other three types directly:

1.direct

If the routing key in the message is the same as the binding key in the Binding, the exchange will send the message to the corresponding queue. The routing key exactly matches the queue name. If a queue is bound to the switch and requires the routing key to be "dog", only messages marked with the routing key "dog" will be forwarded, neither "dog.puppy" nor "dog.puppy" will be forwarded. dog.guard" and so on. It is an exact match, unicast pattern.

2. fanout

Every message sent to a fanout type exchange is distributed to all bound queues. A fanout exchange does not handle routing keys, it simply binds a queue to an exchange, and every message sent to an exchange is forwarded to all queues bound to that exchange. Much like subnet broadcasts, hosts on each subnet get a copy of the message. The fanout type is the fastest to forward messages.

3. Topic

The topic exchange assigns the routing key attribute of the message through pattern matching, and matches the routing key with a certain pattern. At this time, the queue needs to be bound to a pattern. It splits the string of routing keys and binding keys into words separated by dots. It also recognizes two wildcard characters: the symbol "#" and the symbol " " . # Match 0 or more words, no more than one word.