Part 1:  Short introduction to RabbitMQ
Tags: webdev, programming, tutorial, python
Published: 2021-09-12 08:05:29

If you like what I wrote and want to support me, please follow me on [Twitter](https://twitter.com/TheDailyTechTa1) to learn more about programming and similar topics. Also check out my blog with more details about this topic [here](www.thedailytechtalk.com)❤️❤️

In this blog post, we are going to cover an overview of what RabbitMQ is and give an example of when you would apply this technology.   

## What is RabbitMQ?

>RabbitMq is an open source message broker software. sometimes called message-oriented middleware, that originally implemented the Advanced Message Queuing Protocol or >AMQp for short, and has since been extended with a plug-in architecture to support Streaming Text Oriented Messaging Protocol (STOMP), Message Queuing Telemetry >Transport (MQTT), and other protocols.

The simplest way of putting it would be RabbitMQ is used to distribute long-running task that doesn’t require immediate user feedback into a separate process.

Now since we have a good understanding of the definition let’s dive deep into the components of RabbitMq, it’s topology and how we can use it.

RabbitMq has 5 different exchanges:

* Direct exchange
* Fanout exchange
* Header exchange
* Dead Letter exchange
* Topic exchange

## Basic components of RabbitMq 

### Exchanges

| Exchange      | Description |
| ----------- | ----------- |
| __Direct__      | **Direct exchange** delivers messages to queues based on a message routing key. |
| __Fanout__   | **Fanout exchange** routes messages to all of the queues that are bound to it and the routing key is ignored. |
| __Header__   | **Headers exchange** routes messages based on arguments containing headers and optional values. Headers exchanges are very similar to topic exchanges, but route messages based on header values instead of routing keys. |
| __Dead Letter Exchange__   | Provides the functionality to capture messages that are not deliverable.  |
| __Topic__   | **Topic exchanges** route messages to queues based on wildcard matches between the routing key and the routing pattern, which is specified by the queue binding. Messages are routed to one or many queues based on a matching between a message routing key and this pattern. |

### Components

| Exchange      | Description |
| ----------- | ----------- |
| __Binding__ | **Binding** is a “link” that you set up to bind a queue to an exchange. |
| __Routing key__ | **Routing key** The routing key is a message attribute. The exchange might look at this key when deciding how to route the message to queues (depending on exchange type). |
| __Producers__ | Job of the **producer** is to send a new message to the exchange. |
| __Message__ | **Message** represents value you want the consumer to recieve and process. |
| __Queue__ | **Queues** are ordered collections of messages. |
| __Exchange__ | **Exchange** routes the message to the right queue. |
| __Consumers__ | **Consumers** is a client that receives messages. |

## Direct exchange

![Direct exchange topology](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hh2s0px8uwq6bphimuvc.jpg)

A direct exchange delivers messages to queues based on a message routing key. The routing key is a message attribute added to the message header by the producer. Think of the routing key as an "address" that the exchange is using to decide how to route the message. **A message goes to the queue(s) with the binding key that exactly matches the routing key of the message.** 

## Fanout exchange

![Fanout exchange topology](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ikr1ku35qsvejf1b0d3f.png)

A fan-out topology is when the producer sends a message to the exchange and the exchanges ignore the routing key and just sends the task directly to **all** of the queues that are available. 

## Topic exchange
![Topic exchange topology](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qsy29vit1gewdry6xcu1.png)

The logic behind the topic exchange is similar to a direct one - a message sent with a particular routing key will be delivered to all the queues that are bound with a matching binding key. There are two important special cases for binding keys:
* __*__  can substitute for exactly one word.
* __#__  can substitute for zero or more words.

## Dead Letter exchange

There are three identified situations where a message becomes undeliverable after reaching RabbitMQ:

   * A message is negatively acknowledged by the consumer
   * The TTL of a message expires
   * The queue reaches capacity

By default, the broker drops these messages. Publishing is successful, however, the RabbitMQ consumer never handles or has a change to handle the message successfully. 

Queues attached to a dead letter exchange collect dropped messages, with the next steps determined by developer. In other words - it's up to you to decide how to handle messages in the dead letter queue. When implemented correctly, information is almost never lost. 

## Header exchange

![Header exchange topology](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ddpjhah35t7vpxd1b6py.png)

Headers exchange is an exchange which route messages to queues based on message header values instead of routing key. Producer adds some values in a form of key-value pair in message header and sends it to headers exchange. After receiving a message, exchange try to match all or any (based on the value of “x-match”) header value with the binding value of all the queues bound to it.

If you like what I write and want to support me, please follow me on [Twitter](https://twitter.com/TheDailyTechTa1) to learn more about programming and similar topics ❤️❤️