RabbitMQ Basic Concepts

RabbitMQ as a whole is a producer and consumer model that is primarily responsible for receiving, storing, and forwarding messages. Can be the elimination of

When you send a parcel to the post Office, the post Office will be staged and the mail will eventually be sent to the postman for delivery
Person's hand, RabbitMQ is like a system made up of post offices, mailboxes and postman. From the computer terminology level,
The RabbitMQ model is more like a switch model.

Producers and consumers

Producer: The producer is the party that delivers the message.
The producer creates the message and then publishes it to RABBITMQ. A message can generally contain 2 parts: The message body and the label
(Label). The message body can also be called payload, in practical applications, the message body is usually a business logic structure
Data, such as a JSON string. Of course, the message body can be further serialized operations. The label of the message

Used to express this message, such as the name of a switch and a routing key. The producers handed the news to RABBITMQ,
RabbitMQ will then send the message to the interested consumer, C Consumer, according to the label.

Consumer: The consumer is the one who receives the message.

The consumer connects to the RABBITMQ server and subscribes to the queue. When consumers consume a piece of news, they only consume
The message body (payload) of the message. During message routing, the label of the message is discarded, and the messages that are stored in the queue are only
The message body, the consumer will only consume to the message body, also does not know the message producer is who, certainly the consumer also does not need
Know.

Broker: A service node for message middleware.

For RABBITMQ, a rabbitmq Broker can simply be seen as a RABBITMQ service node,
Or a RABBITMQ service instance. In most cases, you can also consider a RABBITMQ Broker as a RABBITMQ
Server.

First the producer carries out the possible packaging of the business party data, which is then encapsulated into a message, sent (the AMQP protocol
The corresponding command is basic.publish) into the broker. Consumers subscribe and receive messages (the AMQP protocol

The command corresponding to the action is basic.consume or basic. Get), the raw data is processed by possible unpacking,
The business processing logic is then followed. This business processing logic does not necessarily need to use the same thread as the logic that receives the message.
The consumer process can use a thread to receive messages and deposit them into memory, such as using Blockingqueue in Java.
The business processing logic uses another thread to read the data from memory, which allows the application to be further extracted, improving the entire application
The processing efficiency.

Queue

Queue: Queues, which are internal objects of the RABBITMQ, used to store messages. Refer to Figure 2-1. The queue can be used in Figure 2-3
Said.

Messages in RabbitMQ can only be stored in the queue, which is contrary to the Katka message middleware. Katka will eliminate
Topic (subject), and the corresponding queue logic is just the displacement in the topic actual storage file
Identity. RabbitMQ producers produce messages and eventually deliver them to the queue, and consumers can get messages from the queue and consume them.
Multiple consumers can subscribe to the same queue, when messages in the queue are evenly distributed (round-robin, polling)
Deal with multiple consumers, not every consumer receives all the message well processing, 2-4 shows.

RabbitMQ does not support broadcast consumption at the queue level, and if broadcast consumption needs to be developed two times, processing logic becomes extremely complex and is not recommended.

Switches, route keys, bindings

Exchange: Exchanger. In Figure 2-4 we can understand for a moment that the producer delivers the message to the queue, actually
This will not happen in the RABBITMQ. The real situation is that the producer sends the message to Exchange (the exchanger, usually also
Can be represented by an uppercase "X"), and the message is routed by the exchanger to one or more queues. If the route is not reached, or
Joyway returned to the producer, perhaps directly discarded. Here you can consider a switch in RABBITMQ as a simple entity,
More details will be covered in later chapters.

There are four types of switches in RabbitMQ, and different types have different routing strategies, which will be exchanged in the next section
Type (Exchange Types).

Routingkey: Route key. When a producer sends a message to a switch, it typically assigns a routingkey,
To specify the routing rules for this message, and this routingkey needs to be associated with the exchanger type and binding key (Bindingkey)
The final entry into force of the combined use.
In the case where the exchanger type and binding key (Bindingkey) are fixed, the producer can send a message to the exchanger,
Specify routingkey to determine where the message flows.

Binding: Bind. In RabbitMQ, a switch is associated with a queue by binding, and when bound, it is generally referred to as

Set a Binding key (Bindingkey) so that RABBITMQ knows how to properly route the message to the queue, 2-6
is shown.

When the producer sends the message to the exchanger, it needs a routingkey when Bindingkey and Routingkey
Messages are routed to the corresponding queue when they are matched. When binding multiple queues to the same switch, these bindings allow
Use the same bindingkey. Bindingkey does not take effect in all cases, it relies on the type of exchanger,
A switch such as the fanout type ignores bindingkey, and instead routes the message to all the queues that are bound to the switch.

For starters, the concepts of switching, route keys, and binding are somewhat obscure and can be
Code listing 1-1 to deepen understanding.
With the metaphor at the beginning of this chapter, the exchanger is the equivalent of a parcel post, routingkey equivalent to filling in the package
Address, Bindingkey equivalent to the destination of the parcel, when filling in the address on the package and actually want to deliver the address to match
, the parcel will be delivered to the destination correctly, and the "master" one by one queue at the end of the destination can retain this
A parcel. If the address is wrong, the postman is not delivered to the destination correctly and the parcel may be returned to the sender and
It is possible to be discarded.
Experienced readers may find that, in some cases, routingkey and Bindingkey can be seen as the same thing.
The code listing 2-1 shows some of the code in Listing 1-1:

The above code declares a direct type of exchanger (the type of the exchanger is described in detail in the next section) and then
The changer and the queue are bound together. Note that the word used here is "Routing_ y", in the case where the bindingkey should be used
The channel. Qu Euebind method uses routingkey in the same way as the Channe L.basicpublish method,
The subtext of this is that the Routingkey and Bindingkey here are the same thing. Under the direct switch type,
Routingkey and Bindingkey need to be fully matched in order to use it, so using this notation in the code above will be handy
Many.

However, under the topic exchanger type, there is a need for a fuzzy match between Routingkey and Bindingkey, which is not
The same.
Bindingkey, in fact, belongs to one of the routing keys, officially interpreted as: The routing key to use for the binding.
Can be translated as: The routing key used when binding. Most of the time, including official documents and RABBITMQ Java API
Bindingkey and Routingkey are regarded as routingkey, in order to avoid confusion, so to understand:

• When binding is used, the routing key required is bindingkey. The client methods involved are as follows:

Channel.exchangebind, channel. Queuebind, corresponding AMQP command (details see
Section 2.2) for Exchange.bind, Queue.bind.

• When sending a message, the required routing key is routingkey. The client methods involved are as follows

Channel. Basicpublish, the corresponding AMQP command is basic.publish.

For some historical reasons, including information that is available, it is customary to use bindingkey in most cases
Written in Routingkey, especially when using the direct type switch. The remainder of this article will also be combined
Called the routing key, readers need to pay attention to distinguish between the differences, can be based on the above identification method to effectively distinguish.

Exchanger type

RabbitMQ commonly used exchanger types are fanout, direct, topic, headers these four kinds. Also mentioned in the AMQP protocol
To two other types: System and custom, which are not described here. For these four types the following one by one illustrates.

Fanout
It routes all messages sent to the switch to all the queues that are bound to the switch.

Direct
The switch routing rules for the direct type are also simple, and it routes messages to those Bindingkey and Routingkey
The exact match in the queue.

In Figure 2-7, for example, the type of exchanger is direct, and if we send a message and set the
Route keys is "warning", the message is routed to Queuel and Queue2, and the corresponding sample code is as follows:
Channel.basicpublish (Exchange_name, "warning",
Messageproperties. Persistent TEXT PLAIN,
Message.getbytes ());

If you set the routing key to "info" or "debug" when sending a message, the message will only be routed to Queue2. Such as
If the message is sent with a different routing key, the message is not routed to both queues.

Topic
The previously mentioned switch routing rules for the direct type are exactly match Bindingkey and Routingkey, but this strict
In many cases, there is no need to meet the needs of the actual business. The topic type of exchanger is on the matching rule.
Extension, which is similar to the switch of direct type and is also a team that routes messages to Bindingkey and Routingkey matches
column, but there are some differences in the matching rules, it contracts:

• Routingkey as a dot ". "Delimited string (by Dot". ") Separate characters for each segment of the partition

String called a word), such as "Com.rabbitmq.client", "Java,util.concurrent", "com.hidden,client";

• Bindingkey and Routingkey are the same number "." A delimited string;
• There can be two special strings "*" and "#" in Bindingkey for fuzzy matching, where "#" is used

  To match a word, ' # ' is used to match multiple-spec words (can be 0).
  Take the configuration in Figure 2-8 as an example:

• Messages Route keys to "Com.rabbitmq.client" are routed to Queuel and Queue2 at the same time;
• Messages Route keys to "Com.hidden.client" are routed only to Queue2:
• Messages Route keys to "Com.hidden.demo" are routed only to Queue2:
• Messages Route keys to "Java.rabbitmq.demo" are routed only to Queuel:

• Route keys for "Java.util. Concurrent "message will be discarded or returned to the producer (need to set
  Mandatory parameter) because it does not match any of the routing keys.

Headers
The headers type of exchanger does not rely on the matching rules of the routing key to route the message, but is based on the content of the message being sent
The Headers property to match. Sets a set of key-value pairs when the queue and the switch are bound, and when the message is sent to the exchanger,
RabbitMQ gets the headers of the message (also the form of a key-value pair), comparing whether the key-value pair is fully
Match the key-value pairs specified by the queue and switch bindings, and if an exact match, the message is routed to that queue, otherwise it will not be routed
to the queue. The headers type of exchanger has a poor performance and is not practical, and basically does not see its presence.

RabbitMQ Basic Concepts