Shall we start with RabbitMQ Exchange Types Explained – Tutorial.
What is RabbitMQ
Basically, software connects and expands through message queues. Besides, they support asynchronous transfer of data between two systems with different bandwidths. Consequently RabbitMQ is a message queuing software (message broker/queue manager) that acts as a broker platform through which various applications send and receive messages.
Additionally, the message aligns separate applications, which facilitates process scaling. Scalability and stability give companies a competitive advantage, as modern consumers expect immediate results and stable systems.
Features of RabbitMQ
How does RabbitMQ work?
- As a message broker, RabbitMQ is used to reduce the load and delivery times of web application servers by delegating times.
- The basic architecture of Rabbitmq is simple.
- Producers create the messages they need to deliver.
- A broker is a message queue that receives messages.
- Other applications, called clients, join the queue and accept sending messages to them.
- After the producers sent the messages, they are kept on the road unless the customer tries to retrieve them.
- Once the message is downloaded, the message journey is complete.
RabbitMQ Exchange Types
Now let’s see how this cycle differs for different types of RabbitMQ exchange.
1. Direct Exchange
The first type of RabbitMQ exchange, direct exchange, uses a message routing key to move messages to queues. Following, a routing key is a message attribute that the producer adds to the message header. Think of a routing key as an “address” that the hub uses to determine where to route a message. Furthermore, a message is delivered to the queue with a binding key that exactly matches the routing key of the message.
Hence, the default exchange for direct exchange is “amq. direct”, which AMQP brokers must provide for communication. As shown in the image, queue A (create_pdf_queue) is directly associated with an exchange (pdf_events) with the binding key “pdf_create”. When a new message arrives directly at the exchange with a routing key of “pdf_create”, the exchanges sends it to a queue where binding key = routing key; which in this example is queue A (create_pdf_queue).
2. Topic Exchange
In addition, topic exchange Sends messages to queues depending on the match between the routing key and the routing pattern wildcard of the queue binding. After that, messages are sent to one or more queues based on a pattern that matches the routing key of the message. There is a lot of dot separated list of words used (.) as the path key.
In fact, the routing patterns have an asterisk (“*”) that matches a word at a specific location in the routing key (for example, the routing pattern “agreements.*.*.b.*” only matches routing keys with “agreements” like the first word and “b” as the fourth word).symbol (” #”) means zero or more word matches.
Subsequently, consumers indicate what topics they are interested in. The consumer creates a queue and binds it to the exchange using a specific routing pattern. All messages with a routing key matching the routing pattern are queued, where they remain until the consumer consumes them. “amx.topic” is the main exchange of topics where AMQP brokers have to provide everything for the exchange of messages.
3. Fanout Exchange
Next one, that is Fanout Exchange works by exchanging fanouts. More precisely, it copies and routes the received message to all possible queues that have any relationship with it, without any dependencies on keys or routing patterns. Furthermore, keys delivered directly are ignored.
Since the fanout hub sends a copy of the message to each queue connected to it, its use cases are quite similar:
- Distributed systems broadcast various state and configuration updates.
- Massively multiplayer online (MMO) games use it for leader board updates or other global events.
- Sports news site use exchanges to deliver performance updates to mobile clients in near real time.
4. Headers Exchange
While, it is designed to handle attributes and it is easier to express as message headers than as a routing key. The changes that occur in the header override the routing key attribute. Therefore, routing uses some attributes that are taken from the headers attribute. Moreover, if the header values are equal to the value specified during binding then the message is considered valid.
Not to mention, it is possible to associate a row with a title change, using more than one header per match. In this case, the broker needs additional information from the developer of the application, i.e. should it consider messages that match some titles or all? So, the mandatory argument for this is “x-match”. In essence, if the “x-match” argument is set to “any”, only one matching header value is sufficient. Alternatively, if you set “x-match” to “all”, all values must match.
“All” and “all” headers starting with the string x are not used to evaluate matches. If “x-match” is set to “some-x- or “all-with-x”, titles starting with the string x- are also used to evaluate matches.
5. Default Exchange
On balance, with Default Exchange, An unnamed, otherwise known as a default trade, has been pre-declared as a direct trade. Usually you should use an empty string for this. When the client or user chooses an exchange, the so called default message, then it is delivered to the queue with the same name, i.e. the routing key. On the whole, through the routing key which is the same as the queue name, each subsequent queue is immediately tied to a default exchange.
Additionally if you define a queue named “search indexing line”, the AMQP broker 0-9-1 binds it to the default exchange using “search indexing online” as the routing key (including the context, sometimes called the binding key ). Therefore, in the default exchange, a message sent with the “search indexing online” routing key is routed to the “search indexing online” queue. In other words, default exchange allows messages to be delivered directly to queues, even if this is not technically possible.
6. Dead letter exchange
Evidently, some queue consumers may not handle certain alerts, and certain events may cause the queue itself to drop messages. For example, a message is rejected if there is no response queue. In this case, Dead Letter Exchanges must be enabled so that these messages can be saved and reprocessed later. Dead Letter Exchange is an AMQP extension provided by RabbitMQ. This exchange has the ability to catch undeliverable messages.
That is it. Thank you for reading RabbitMQ Exchange Types Explained – Tutorial. We shall conclude.
RabbitMQ Exchange Types Explained – Tutorial Conclusion
To summarize, this article introduces you RabbitMQ exchange types. Of course, it is very important to start with the replacement according to your case. When fanout acts as direct exchange, only when the key of the given association of all possible queues is literally the same. Then the extensive use of exchange can greatly simplify the queuing architecture for us.