What is a message broker? Overview of RabbitMQ and demo application

Tram Ho

In cloud architecture (or microservices), applications are divided into smaller independent blocks that can be easily developed, deployed and maintained. Imagine you have a cloud architecture that has many services and many requests per second, you must ensure that no one request is lost and your web service is always ready to receive new requests instead of locked by are handling previous requests as well as ensuring that services communicate with each other smoothly and effectively.

So how do you do? The answer is the Message Broker !

What is a message broker?

A message broker (also known as an integration broker or interface engine ) is an intermediary module that transports messages from sender to receiver. It is an architentural pattern for checking, forwarding and navigating messages ; mediate between applications, minimize communication between them, and to maximize the efficiency of splitting up smaller blocks. The main task of a Message broker is to receive messages from applications and perform a certain action. Let’s look at the sequence diagram below:

Message Broker pattern sequence diagram

As you can see, during Initialize , Service1 and Sevice2 init, then load the proxy and register to Broker. From there, Broker will forward the messages to the proxy that has been registered before. This pattern will have the following benefits:

  • Service1 and Service2 do not need to know each other. It only needs to send a message to the proxy, from which the proxy will forward the message to Broker. From there Broker will forward messages to Service1 and Service2 that they have previously registered to receive messages.
  • Service1 and Service2 communicate via Broker, so even though there is a language difference, they can communicate successfully.
  • With this design pattern, we can set up asynchronous mechanism. For Service1 , it doesn’t need to care when the message reaches Service2 or when Service2 is finished, it only needs to send the message to the Message Broker . Service2 will retrieve the message whenever it wants. This feature can be leveraged to build log storage and processing systems.

Currently, there are many message broker software that can be mentioned such as: Amazon Web Services (AWS) Simple Queue Service (SQS) , Apache Kafka , Apache ActiveMQ . But the most popular of these names is RabbitMQ !

What is RabbitMQ?

RabbitMQ is an open-source Message broker , originally used for the Advanced Message Queuing Protocol (AMQP) , which was later developed to support Streaming Text Oriented Messaging Protocol (STOMP) , Message Queuing Telemetry Transport (MQTT) , and other other protocols. However, in this article, I will not go into the above protocols. RabbitMQ is written in Erlang , an uncommon language but quite suitable for the message Broker ‘s work.

RabbitMQ and in messaging generally use the following techniques:

  • Producing means simply sending . The messaging application is called Producer .

  • Queue is a post box located in RabbitMQ . Messages move through RabbitMQ and your application, but they can only be stored in the queue . Queue is limited to memory and disk of the host. In essence, it is a message cache with large data. Many producers can send messages to a queue and many consumers can receive data from a queue :

  • Consuming has the same meaning as receiving . Consumer is an application that is primarily waiting to receive messages :

Note that the producer , consumer and broker do not need to depend on the same host. In fact, there are very few such applications. An application can be both a producer and a consumer .

Hello World!

In this article, we will use the Bunny Ruby Client as an example of a producer sending messages and a consumer receiving messages and printing them to the screen. In the picture below, P is the producer and C is the consumer , the middle box is a queue :

First, we install Bunny:


We will write message producer in sender.rb and message consumer in receiver.rb . The producer will connect to RabbitMQ , send a message and exit .

connection will take a socket connection , handle the version of the protocol, authenticate, and so on. In this example, we will connect to the local , if we want to connect to another host , just use the option :hostname and specify its domain name or IP address. Next, we create a channel , a queue to send the message :

The queue will only be created if it does not already exist, the message is a byte array so you can pass anything you want. Finally, we close connecion :


Now, consumers will listen for messages from RabbitMQ . Unlike producers , consumers will run to listen to messages and print them to the screen.

Similar to producers , we open the connection and channel , declare the queue , note that the name of the queue must be the same as the queue in sender.rb :

Here, we also declare the queue to make sure that the queue existed before the consumer message .

Bunny::Queue#subscribe will deliver the message from the queue and it is also a callback that is executed when RabbitMQ pushes the message to the consumer asynchronously:

Here, to prevent receiver.rb from ending immediately, Bunny::Queue#subscribe uses a block to wait for the thread to execute.

Now, run consumer :

Then run sender :

The consumer will print the message it receives from the producer via RabbitMQ . Consumer will keep running to wait for the message .

Try running the producer on another terminal to get a better idea!


Share the news now

Source : Viblo