[RabbitMQ—Basics] Overview

Introduction

Message Queue Middleware (MQ for short) refers to the use of efficient and reliable message delivery mechanisms for platform-independent data exchange, and the integration of distributed systems based on data communication. By providing message passing and message queuing models, it can expand the communication between processes in a distributed environment.

There are many open source message middlewares, and the more mainstream ones are RabbitMQ, Kafka, ActiveMQ, RocketMQ, etc. Message-oriented middleware provides a mechanism for integrating applications in a loosely coupled and flexible manner.

Message middleware is suitable for distributed environments that require reliable data transmission. Different objects in the system using message middleware activate each other's events by passing messages to complete corresponding operations. Message middleware is often used to shield the characteristics of various platforms and protocols, and to achieve collaboration between applications. Its advantage is that it can provide synchronous and asynchronous connections between clients and servers, and can be used at any time. Messages are transmitted or stored and forwarded.

The purpose of message middleware can be summarized as follows:

Decoupling
redundancy
Peak clipping
Recoverability
Order guarantee
buffer
Asynchronous communication

RabbitMQ is a message middleware that uses Erlang language to implement AMQP (Advanced Message Queuing Protocol, Advanced Message Queuing Protocol). It has excellent performance in terms of ease of use, scalability, reliability and high availability.

install

Manual installation of RabbitMQ is more cumbersome, here is a simple Docker-based installation method:

docker run -d --name rabbitmq --hostname my-rabbitmq -p 5672:5672 -p 15672:15672  -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin [拉取的RabbitMQ镜像id]

core concept

RabbitMQ is a producer and consumer model as a whole, mainly responsible for receiving, storing and forwarding messages. In terms of computer terms, the RabbitMQ model is more like a switch model. The overall model architecture of RabbitMQ is shown in the figure below:

Producer: Producer

The producer creates a message and then publishes it to RabbitMQ. The message can generally contain two parts: the message body and the label. In practical applications, the message body is generally data with a business logic structure, such as a JSON string. The label of the message is used to express the message, such as the name of a switch and a routing key. The producer hands the message to RabbitMQ, and RabbitMQ will then send the message to interested consumers (Consumers) based on the tag.

Consumer: Consumer

The consumer connects to the RabbitMQ server and subscribes to the queue. In the process of message routing, the label of the message is discarded, and the message stored in the queue is only the message body, and consumers will only consume the message body.

Broker: Service node

For RabbitMQ, a RabbitMQ Broker can be simply regarded as a RabbitMQ service node, or RabbitMQ service instance. In most cases, a RabbitMQ Broker can also be regarded as a RabbitMQ server.

Queue: Queue

The producer of RabbitMQ produces messages and finally delivers them to the queue. Consumers can get messages from the queue and consume them. Multiple consumers can subscribe to the same queue. At this time, the messages in the queue will be equally distributed (Round-Robin, or polling) to multiple consumers for processing by default, instead of each consumer receiving all Messages and processing, RabbitMQ does not support broadcast consumption at the queue level.

Exchange: Exchange

producer does not send the message directly to the queue, but sends the message to the exchange, and the exchange routes the message to one or more queues. If the route is not available, it will be returned to the producer or discarded directly according to the configuration. switches, and different types have different routing strategies.

BindingKey: binding key

RabbitMQ, the exchange is associated with the queue through binding. When binding, a binding key generally specified, so that RabbitMQ knows how to correctly route messages to the queue.

RoutingKey: routing key

When the producer sends a message to the switch, it usually specifies a RoutingKey to specify the routing rules of the message, and this RoutingKey needs to be used in conjunction with the switch type and binding key to finally take effect. switch will match the routing key and the binding key according to its own type. If the match is successful, the message will be forwarded to the corresponding queue.

Connection: Connect

Both producers and consumers need to establish a TCP connection with RabbitMQ Broker. This connection is Connection.

Channel: Channel

Once the TCP connection is established, the client can create an AMQP channel, and each channel will be assigned a unique ID. The channel is a virtual connection established on the Connection, and each AMQP command processed by RabbitMQ is completed through the channel.

Note: In a multi-threaded application scenario, each thread corresponds to a channel and multiplexes the same connection, which can improve performance and facilitate management at the same time.

switch type

There are four types of exchanges commonly used by RabbitMQ: fanout, direct, topic, and headers.

fanout

The fanout type switch will route all messages sent to the switch to all queues bound to the switch, and will shield the role of routing keys and binding keys.

direct

The direct type exchange will route the message to those queues where the BindingKey and RoutingKey exactly match.

topic

The topic type exchange has been extended in the matching rules. It is similar to the direct type of exchange. It also routes the message to the queue that matches the BindingKey and RoutingKey, but the matching rules here are somewhat different. It has the following conventions:

RoutingKey is a string separated by dot ".", such as "com.rabbitmq.client".
BindingKey and RoutingKey are also strings separated by dots ".".
There can be two special strings "*" and "#" in the BindingKey, which are used for fuzzy matching, where "#" is used to match one word, and "#" is used to match one or more words (it can be zero) .

headers

Exchangers of the headers type do not rely on the matching rules of the routing key to route messages, but perform matching based on the headers attribute in the message content sent. Develop a set of key-value pairs when binding the queue and the exchange. When sending a message to the exchange, RabbitMQ will get the message headers, and compare whether the key-value pairs completely match those specified when the queue and the exchange are bound. A key-value pair. If an exact match, the message will be routed to this queue, otherwise it will not be routed to this queue. The headers type of exchanger has poor performance and is not practical, basically you will not see its existence.

operation process

Now summarize the entire use process of RabbitMQ. The first is the producer:

The producer connects to RabbitMQ Broker, establishes a connection, and opens a channel.
The producer declares a switch and sets related properties, such as switch type, whether it is persistent, etc.
The producer declares a queue and sets related properties, such as whether it is exclusive, whether it is persistent, whether it is automatically deleted, etc.
The producer binds the switch to the queue through the routing key.
The producer sends a message to RabbitMQ Broker, which contains information such as routing keys and exchanges.
The corresponding switch finds a matching queue according to the received routing key.
If found, the message sent from the producer is stored in the corresponding queue.
If it is not found, it will be discarded or returned to the producer according to the attributes configured by the producer.
Close the channel.
Close the connection.

For consumers:

Consumers connect to RabbitMQ Broker, establish a connection, and open a channel.
Consumers request RabbitMQ Broker to consume messages in the corresponding queue (push mode), may set the corresponding callback function, and do some preparations.
Waiting for RabbitMQ Broker to respond and deliver the message in the corresponding queue, and the consumer receives the message.
The consumer acknowledges (ack) the received message.
RabbitMQ deletes the corresponding confirmed message from the queue.
Close the channel.
Close the connection.