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.
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.
We can use ‘OldSound/RabbitMqBundle’ to integrate RabbitMQ with a PHP application.
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:
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.
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.
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.
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.
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.
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.
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.
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 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.