RabbitMQ basic concepts

RabbitMQ introduction

RabbitMQ, also known as RabbitMQ, is one of the most popular open-source middleware for the Internet and traditional industries. RabbitMQ 1.0, based on the AMQP standard, was released by Rabbit Technologies in 2007.

Basic features of RabbitMQ

  • High reliability, easy expansion, high availability, and rich functions

  • Support for most programming language clients.

  • RabbitMQ follows the AMQP protocol and is written in Erlang.

  • RabbitMQ also supports other protocols such as MQTT

  • RabbitMQ also has great plug-in extension capabilities,

RabbitMQ overall architecture

RabbitMQ architecture member concepts

They are both producers.

Message producer

A Consumer

Message consumer

Connection

TCP connection between producer/consumer and broker

Channel

A Channel is a logical connection established within a connection. If the application supports multiple threads, each thread usually creates a separate Channel for communication. The AMQP Method contains a channel ID to help the client and Message Broker identify channels, so they are completely isolated from each other. Channel as a lightweight Connection greatly reduces operating system construction

Brokder

The application that receives and distributes messages, RabbitMQ Server is Message Broker

Virtual host

Designed for multi-tenant and security reasons, the basic components of AMQP are divided into virtual groups, similar to the namespace concept in the network. When different users use the same RabbitMQserver service, multiple vhosts can be partitioned and each user can create an exchange/queue at their own Vhost

Exchange

Message arrives at the first stop of the broker, matches the Routingkey in the query table, and dispatches messages to the queue according to the distribution rules. Common switches include point-to-point (direct), publish-subscribe (topic), andfanout (multicast)

Queue

This is where the message is eventually sent to be picked up by the consumer

Binding

A virtual connection between exchanges and queues. A Binding can contain a Routingkey. Binding information is stored in the query table in exchange and used as a basis for message distribution

The RabbitMQ Exchange type

The types of switches for RabbitMQ are FANout, Direct, Topic, or headers.

The fanout exchange

The FANout exchange routes all messages sent to the exchange to all queues bound to the exchange.

As shown in the figure, there are three queues under the FANout switch bound to the switch, so the switch will send the message to each queue after it is sent. If the consumer is not online, so not online during the message sent over is not received, after the line is not received, only online state can receive the message, equivalent to broadcast, broadcast, if online know, not online also do not know.

Direct switch

The direct exchange routing rule is simple and routes messages to queues where BindingKey and RoutingKey match exactly.

As shown in the figure, the direct switch checks whether the routing key and binding key match completely. If they match completely, the direct switch must enter the specified queue. If the routing key and binding key do not match, the direct switch cannot enter the corresponding queue. Consumers only consume messages that conform to the rules.

Topic switches

Topic types of exchanges extend the direct matching rule and also route messages to queues that match BindingKey and RoutingKey.

Topic matching rules are different from the direct matching rules. Topic convention: BindingKey and RoutingKey are both “.” delimited strings; Two special characters, “” and “#”, can exist in BindingKey for fuzzy matching, where “” is used to match one word and “#” is used to match multiple words (possibly zero).

Headers switches

A HEADERS exchange does not rely on the matching rules of the routing key to route information, but matches the HEADERS attribute in the content of the sent message.

When a message is sent to the exchange, RabbitMQ will retrieve the headers of the message and compare whether any of the key/value pairs match the headers specified in the queue/exchange binding. If so, the message will be routed to the queue. Headers switches have poor performance and are generally not recommended.