RabbitMQ

Introduction

RabbitMQ is a message-queuing software called a message broker or queue manager. It is a software where queues can be defined, applications may connect to the queue and transfer a message onto it. In short, RabbitMQ is a message broker that accepts and forwards messages.
A message can include any kind of information like a text message, process ID etc. The queue-manager software stores the message until a receiving application connects and takes a message off the queue. The receiving application then processes the message in an appropriate manner.

When and Why should we use RabbitMQ?

Message queuing allows web servers to respond to requests quickly instead of being forced to perform resource-heavy procedures on the spot. Message queuing is also good when you want to distribute a message to multiple recipients for consumption or for balancing loads between workers.
The consumer can be on a totally different server than the publisher, or they can be located on the same server. The request can be created in one programming language and handled in another programming language – the two applications will only communicate through the messages they are sending to each other. Due to that, the two applications will have a low coupling between the sender and the receiver.

Implementation

We can use ‚OldSound/RabbitMqBundle‘ to integrate RabbitMQ with a PHP application.

Consumer Class:

Producer Configuration:

Consumer Configuration:

Advantages

• Reliability: RabbitMQ offers a variety of features like persistence, delivery acknowledgments, publisher confirms and high availability.
• Flexible Routing: Messages are routed through exchanges before arriving at queues. RabbitMQ features several built-in exchange types for typical routing logic.
• Clustering: Several RabbitMQ servers on a local network can be clustered together, forming a single logical broker.
• Federation: RabbitMQ offers a federation model for servers that need to be more loosely and unreliably connected than clustering allows.
• Highly Available Queues: queues can be mirrored across several machines in a cluster, ensuring that even in the event of hardware failure your messages are safe.
• Multi-Protocol: RabbitMQ supports messaging over a variety of messaging protocols.
• Many Clients: There are RabbitMQ clients for almost all languages.
• Tracing: RabbitMQ offers tracing support if your messaging system is misbehaving to find out what’s going on.

RabbitMQ Workflow

A message broker can act as a middleman for various web application. They can be used to reduce loads and delivery times by web application servers since tasks, which would normally take quite a bit of time to process.

The basic architecture of a message queue:

• Producers create messages and deliver them to the broker (the message queue).
• Consumers receive the message and process it as per the requirement.
• Exchange performs routing of the message to the queues.
• Queue stores the message until a consumer receives the message.

A software can be a producer, or consumer, or both a consumer and a producer and a producer of messages. Messages placed onto the queue are stored until a consumer retrieves them.

Hello World using the php-amqplib Client

 

In the diagram, „P“ is our producer and „C“ is our consumer. The box in the middle is a queue – a message buffer that RabbitMQ keeps on behalf of the consumer.

The php-amqplib client library

RabbitMQ supports multiple protocols. There are a number of clients for RabbitMQ in many different languages. We use the php-amqplib and Composer for dependency management.
Add a composer.json file to your project:

Provided you have Composer installed and functional, you can run the following:

php-amqplib library installed now.

Sending

We’ll call our message publisher (sender) send.php and our message receiver receive.php. The publisher will connect to RabbitMQ, send a single message and then exit.
In send.php, we need to include the library and use the necessary classes:

Then we create connection to the server.

The connection abstracts the socket connection, and takes care of protocol version negotiation and authentication and so on for us. Here we connect to a broker on the local machine – hence the localhost. If we wanted to connect to a broker on a different machine we’d simply specify its name or IP address here.

Next we create a channel, which is where most of the API for getting things done resides.

To send, we must declare a queue for us to send to; then we can publish a message to the queue:

Declaring a queue is idempotent – it will only be created if it doesn’t exist already. The message content is a byte array, so you can encode whatever you like there.

Lastly, we close the channel and the connection.

Receiving

We will keep our receiver running to listen for messages and print them out.
The code in receive.php has almost the same ‘include’ and ‘use’ as send.

Setting up is the same as the publisher; we open a connection and a channel and declare the queue from which we’re going to consume.

We start the consumer before the publisher in order to make sure the queue exists before we try to consume messages from it. Then we will define a PHP callable that will receive the messages sent by the server. Messages are sent asynchronously from the server to the clients.

Our code will block while our ‘$channel’ has call-backs. Whenever we receive a message our ‘$callback’ function will be passed the received message.

Exchange

Messages are not published directly to a queue, instead, the producer sends messages to an exchange. An exchange is responsible for the routing of the messages to the different queues. An exchange accepts messages from the producer application and routes them to message queues with the help of bindings and routing keys. A binding is a link between a queue and an exchange.

Message Flow in RabbitMQ

1. The producer publishes a message to an exchange. When we create the exchange, we have to specify the type of it.
2. The exchange receives the message and is now responsible for the routing of the message. The exchange takes different message attributes into account, such as routing key, depending on the exchange type.
3. Bindings have to be created from the exchange to queues. In this case, we see two bindings to two different queues from the exchange. The Exchange routes the message into the queues depending on message attributes.
4. The messages stay in the queue until they are handled by a consumer.
5. The consumer handles the message.

Queue

Queues stores the messages that are consumed by connected applications. A queue must be declared before it can be used. Declaring a queue will create the queue if it doesn’t exists. If the attributes of declared queue are different from the existing queue channel-level exception occurs.

Properties

1. Name
2. Durable (survive a broker restart)
3. Exclusive (used by only one connection and the queue will be deleted when the connection closes).
4. Auto-delete (queue is deleted after the last consumer unsubscribe).
5. Arguments (used to implement additional features)

Consumer

Consumer is an application that receives a message from the queue. There are two different ways to do this. Push API (have the message delivered to them) and Pull API (fetch messages as needed). With the “push API” application have to indicate interest in consuming messages from a particular queue. It is possible to have more than one consumer per queue or to register an exclusive consumer. Each consumer has an identifier called a consumer tag that can be used to unsubscribe from messages.