Middleware: Overview RabbitMQ

Carlos -

Concept


RabbitMQ is a message-queuing software that can be thought of as a middleman message carrier or a queue manager. Simply put, it is a software where queues are defined, serving applications with the purpose of transporting one or more messages.

You have a web service that receives a very large number of requests per second and needs to ensure that no requests are lost. And your web service is always ready to accept new requests instead of being locked up processing previous ones. The idea here is to put them into a queue between the web service and the processing service. This ensures that the two processes are completely separate. Additionally, the queue will store the requests, ensuring none are lost when their volume becomes very large.

Basic Concepts in RabbitMQ

  • Producer: Application that sends messages.
  • Consumer: Application that receives messages.
  • Queue: Stores messages.
  • Message: Information transmitted from the Producer to the Consumer through RabbitMQ.
  • Connection: A TCP connection between the application and the RabbitMQ broker.
  • Channel: A virtual connection within a Connection. Publishing or consuming from a queue is done on the channel.
  • Exchange: The place that receives messages published from the Producer and pushes them into queues based on the rules of each type of Exchange. To receive messages, a queue must be part of at least one Exchange.
  • Binding: Takes on the task of linking between Exchange and Queue.
  • Routing key: A key that the Exchange uses to decide how to route messages to queues. Essentially, the routing key is the address for the message.
  • AMQP: Advanced Message Queuing Protocol, the messaging protocol used in RabbitMQ.
  • User: To access RabbitMQ, one must have a username and password. In RabbitMQ, each user is assigned certain permissions. Users can be specifically authorized for a particular Vhost.
  • Virtual host/Vhost: Provides distinct ways for applications to share a RabbitMQ instance. Different users can have different permissions for different vhosts. Queues and Exchanges can be created, so they only exist within one vhost.

Types of Exchanges


Direct Exchange
Direct Exchange routes messages to queues based on the routing key. It is typically used for unicast routing (although it can be used for multicast routing). The routing steps for messages:
- A queue is bound to a direct exchange by a routing key K.
- When a new message with routing key R arrives at the direct exchange, the message will be delivered to that queue if R=K.

Default Exchange

Each exchange is assigned a unique name, the default exchange essentially is a direct exchange but with no name (empty string). It has a special feature that makes it very useful for simple applications: every queue created is automatically linked to it with a routing key identical to the queue's name.

For example, if you create a queue named "hello-world", the RabbitMQ broker will automatically bind the default exchange to the "hello-world" queue with the routing key "hello-world".
Fanout Exchange
Fanout exchange routes messages to all queues that it encompasses, ignoring the routing key. Assume it surrounds N queues; when a new message is published, the exchange will transport the message to all N queues. Fanout exchange is used for broadcasting messages.



Topic Exchange
Topic exchange routes messages to one or more queues based on the match between the routing key and pattern. Topic exchanges are often used to perform multicast messaging. Some use cases include:
- Distributing data related to specific geographical locations.
- Processing background tasks performed by multiple workers, each capable of handling specific groups of tasks.
- Updating news related to categorization or tagging (e.g., only for a specific sport or team).
- Coordinating different types of services in the cloud.



Headers Exchange
Header exchange is designed for routing with multiple attributes, more easily performed as message headers rather than a routing key. In this case, the broker needs one or more pieces of information from the application developer, specifically, to care about messages with which headers match or all of them.

Thank you for your  reading!