This is the 14th day of my participation in the August More Text Challenge. For details, see: August More Text Challenge

Core components of RabbitMQ

Before looking at the four switches of RabbitMQ, we need to look at the core components of RabbitMQ and the core concepts associated with it.

The core concept

Server: Also known as Broker, is a node of the messaging middleware service that receives connections from customers and implements AMQP entity services.

Connection: A Connection, a network Connection between the application and the Broker, three TCP/IP handshakes and four waves, a Connection containing hundreds of channels

Channel: Channel. Almost all operations are performed in a Channel. A Channel provides a Channel through which messages are read and written. A Channel is a virtual connection built over a TCP connection. Rabbitmq creates multiple channels over a TCP connection to allow multiple threads to process the TCP connection. This TCP is shared by multiple threads, each of which corresponds to a Channel on the TCP connection.

Message: The data that is passed between the service and the application. It consists of Properties, which modifiers messages such as their priority, latency, and other advanced features, and Body, which is the content of the message.

Virtual Host: Virtual messaging server. Each Virtual Host is a separate RabbitMQ server. Each Virtual Host is isolated from each other. Exchanges, queues, and messages cannot communicate with each other. You can think of RabbitMQ as a database, and Virtual Host is one of the libraries.

Exchange: The switch receives the messages, sends the messages to the message Queue bound to the routing key (which does not have the capacity to store messages), and delivers the messages to the Queue. If there is no Queue bind to the Exchange, the switch directly discards the messages sent by the Producer. Common switch types are Direct, FANout, TOPIC, and HEADERS

Binding: Virtual connection between the Exchange switch and Queue. Multiple routing keys can be protected in the binding

Routing key: A Routing rule that allows VMS to route a message from the switch to a bound queue.

Queue: a Queue that holds messages from which consumers can get them.

RabbitMQ There are four types of switches

direct(routing key)

Process routing keys. You need to bind a queue to the switch and require that the message match exactly with a particular routing key. This is a complete match, meaning that the routing key needs to be identical. If a queue is bound to the switch with binding key “SMS”, only messages with routing key “SMS” specified when the message is sent will be forwarded to the queue, not to eAMIL or SMS. ABC. Only SMS will be forwarded. Therefore, messages sent with a specific routing key will be delivered to all queues bound with the matching binding key. In addition, RabbitMQ allows a queue to be bound to a switch through multiple binding keys. When a switch sends a message, the message can be routed to the specified queue as long as the routing key specified by the producer satisfies one of the binding keys. As shown in the figure below, as long as the producer sends a message with a routing key of SMS or test, the message can be delivered to Queue2. (The bingding key here is also called a routing key, just to distinguish it from the routing key specified when sending the message.)

Test the Direct switch on the Web

  1. First, add a switch in direct mode nameddirect-exchange

  1. Create queues queuE1 and QueuE2 and bind them with names asdirect-exchangeOn the switch, and specify the Binging key for each queue (Note: The binding can be either on the switch or on the queue to the switch).
  • queue1

  • queue2

  • The following switches are bound:

  1. The switch specifies the routing key when sending messages to the queue. The messages are delivered to the specified queue based on the routing key (the Web side directly specifies the Binging key in the switch. In actual production, the binging key is specified when the producer sends messages)

  1. It is clear that the message was indeed delivered to Queue1, because queuE1 is associated withdirect-exchangeSpecify the bingding key assms, and the routing key specified by the sending message is also"SMS", so the message is sent to Queue1.

  • Get the message from queue queuE1

Fanout switch

Routing keys are not processed. Simply bind the queue to the switch. A message sent to a switch is forwarded to all queues bound to the switch. Much like a subnet broadcast, each host in the subnet gets a copy of the message. The Fanout switch is the fastest to forward messages.

Test the Fanout switch on the Web

  1. Create a switch of the Fanout type

  1. Bind the two queues queuE1 and QueuE2 above to the fanout switch without specifying the Bindinging key this time.
  • queue1

  • queue2

  1. After the queue binding is complete, the switches are as follows

  1. The Fanout switch sends a message without specifying a routing key. Which queue will receive the message?

  • Obviously, queuE1 and QueuE2, which are bound to the FanOut-Exchange switch, both receive messages from the switch. This is a Fanout-type switch that broadcasts messages to all queues bound to it.

Topic (fuzzy matching routing key)

Topic switches can implement more complex message sending rules, that is, when sending messages, they specify more complex routing keys, similar to fuzzy matching. Routing keys can be changeable. As long as the specified routing key matches the binding key binding between the switch and the queue, the message can be correctly delivered to the specified queue.

  • Fuzzy matching symbols and their rules

    # : matches one or more, or none. Supports multiple levels

    * : If the binding key is *.sms.*, only messages with a routing key such as A.sm. B will be sent to the queue. If the routing key is SMs. b or A.ms or A.B.ms, the routing key will not be delivered to the queue.

Test a topic switch on the Web

  1. Create a new topic switch namedtopic-exchange
  2. The previous queuE1 and Queue2 are bound to the Topic-Exchange switch. Unlike the direct switch, the binding key is fuzzy.
  • Queue1, specify binding key as*.sms.*

  • Queue2, specify binding key as#.email

  1. The switch of the topic type is bound to the queue

  1. First, the topi-type switch sends a message (with two queues bound to the switch) with a routing key ofa.sms.bWhich queue will the message be delivered to, or none at all?

  • Yes, only queue QUEUe1 receives the message because we specifiedrouting key = a.sms.b, andbinding key=*.sms.*Matches, so the message can be delivered correctly. The diagram below:

Next, we send two messages with routing keys email and A.B.e-mail

  • First message

  • Second message

  • Obviously, both messages were successfully sent to QueuE2 and were not sent to any other queue, because both messages had a routing key that matched queuE2 and a binding key bound to the switch, and thus were correctly matched.

Headers type switches

A HEADERS switch is similar to a topic switch. However, the routing of a TOPIC switch is based on the routing key, while the routing of a HEADERS switch is based on the HEADERS data of messages. Therefore, specifying a routing key has no effect when sending messages to a HEADERS switch. The switch of the headers type needs to specify Arguments when binding the queue. The message can be sent to the corresponding queue only when the headers and Arguments match.

Testing a HEADERS switch on the Web end

  1. Create a switch of the headers type and name it headers Exchange

  2. Bind queuE1 and QueuE2 to the headers exchange switch. You do not need to specify a binding key, but you need to specify Arguments.

  • Queue1, specify Arguments asx = 1

  • Queue2: specifies Arguments to bey = 1

  1. The HEADERS switch after the queue binding is complete

  1. If the switch of the header type sends a message, set headers tox=1

  • Obviously, the message is posted to QueuE1 because the headers and queue queue1 specified when the message is sent match the Arguments bound to the switch, so the message is correctly posted to Queue1.

  • Next, we test to specify multiple headers when sending a message to see which queues the message will be sent to, specifying two headers asx=1andy=1

  • As you can see below, messages are posted to both queuE1 and Queue2 queues. Because both headers match the Arguments defined when QueuE1 and Queue2 are bound to the switch, messages can be routed to both queues.

  • Similarly, if neither headers nor Arguments match when you post a message, you will be prompted that the message cannot be routed to any queue bound to it. If Arguments matches only one headers, only that queue will receive the message.

conclusion

A direct switch needs to process routing keys. When sending messages, a direct switch needs to specify a routing key. Messages are routed to the specified queue according to the routing key. Fanout is a switch that does not handle routing keys, and messages are sent to all queues bound to the switch in broadcast mode. Topic exchanges will post messages to the queues according to certain rules and routing keys, which is more flexible than direct. A switch of the headers type sends a message based on headers rather than routing key. You need to specify Arguments when you bind a message to a queue. If only the specified HEADERS matches the Arguments that are used when you bind a message to a queue, you need to specify Arguments when you send a message. The message will be delivered correctly.

🏁 This is an introduction to the four types of RabbitMQ switches. If there are any errors, please leave a comment to correct them. If you find this article helpful, please click 👍 😋😻😍