RabbitMQ is a message-queueing software called a message broker or queue manager. Simply said; It is a software where queues can be defined, applications may connect to the queue and transfer a message onto it.
A message can include any kind of information. It could, for example, have information about a process/task that should start on another application (that could be on another server), or it could be just a simple text message. The queue-manager software stores the messages until a receiving application connects and takes a message off the queue. The receiving application then processes the message in an appropriate manner.
All articles from Getting Started with RabbitMQ can be downloaded as a free ebook here.
Gives a brief understanding of messaging and important RabbitMQ concepts are defined
Step-by-step instructions which shows how to set up a connection, how to publish to a queue, and how to subscribe from the queue
Describes how to monitor and handle your RabbitMQ server from a web browser
Explains the different types of exchanges in RabbitMQ and how exchanges and queues are associated with each other
A message brooking solutions can act like a middleman for various services (e.g. a web application, as in this example). 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, can be delegated to a third party whose only job is to perform them.
In this guide, we follow a scenario where a web application allows users to upload information to a web site. The site will handle this information and generate a PDF and email it back to the user. Handling the information, generating the PDF and sending the email will in this example case take several seconds and that is one of the reasons of why a message queue will be used.
When the user has entered user information into the web interface, the web application will put a "PDF processing" - task and all information into a message and the message will be placed onto a queue defined in RabbitMQ.
The basic architecture of a message queue is simple, there are client applications called producers that create messages and deliver them to the broker (the message queue). Other applications, called consumers, connects to the queue and subscribes to the messages to be processed. A software can be a producer, or consumer, or both a consumer and a producer of messages. Messages placed onto the queue are stored until the consumer retrieves them.
Message queueing allow web servers to respond to requests quickly instead of being forced to perform resource-heavy procedures on the spot. Message queueing is also good when you want to distribute a message to multiple recipients for consumption or for balancing loads between workers.
The consumer can take a message of the queue and start the processing of the PDF at the same time as the producer is queueing up new messages on the queue. The consumer can be on a totally different server than the publisher, or they can be located on the same server. 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.
1. The user sends a PDF creation request to the web application.
2. The web application (the producer) sends a message to RabbitMQ, including data from the request, like name and email.
3. An exchange accepts the messages from a producer application and routes them to correct message queues for PDF creation.
4. The PDF processing worker (the consumer) receives the task and starts the processing of the PDF.
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 the link between a queue and an exchange.
In Part 2 of the tutorial are only direct exchanges used. Deeper understanding about the different exchange types, binding keys, routing keys and how/when you should use them can be found in part 4 about exchanges: Part 4: RabbitMQ for beginners - Exchanges, routing keys and bindings.
Here are some important concepts that needs to be described before we dig deeper into RabbitMQ. The default virtual host, the default user, and the default permissions are used in the examples that follow, but it is still good to have a feeling of what it is.
At the beginning of this article series we had one producer (the website application) and one consumer (the PDF processing application). If the PDF processing application crashes, or if there is a lot of PDF requests coming in the same time, messages would continue to stack up in the queue until the consumer starts again. It would then process all the messages, one by one.
To be able to follow this guide you need to set up a CloudAMQP instance or you need to download and install RabbitMQ. CloudAMQP is a hosted RabbitMQ solution, meaning that all you need to do is sign up for an account and create an instance. You do not need to set up and install RabbitMQ or care about cluster handling, CloudAMQP will do that for you. CloudAMQP can be used for free with the plan little lemur. Go to the plan page and sign up for any plan and create an instance.
When your instance is created, press on details for your instance to find your username, password and connection URL for your cloud hosted RabbitMQ instance.
Immediately after a RabbitMQ instance has been created it is possible to send a message cross languages, platforms and OS. This way of handling messages decouple your processes and creates a highly scalable system. You can now start by opening the management interface to get an overview of your RabbitMQ server.
RabbitMQ provides a web UI for management and monitoring of your RabbitMQ server. The RabbitMQ management interface is enabled by default in CloudAMQP and a link can be found on the details page for your CloudAMQP instance.
From the management interface, it is possible to handle, create, delete and list queues. It is possible to monitor queue length, check message rate, change and add users permissions much more.
More information about the management interface can be found in Part 3 - The management interface.
RabbitMQ speaks a protocol called AMQP by default. To be able to communicate with RabbitMQ you need a library that understands the same protocol as RabbitMQ. You need to download the client-library for the programming language that you intend to use for your applications. A client-library is an applications programming interface (API) for use in writing client applications. A client library has several methods that can be used, in this case to communicate with RabbitMQ. The methods should be used when you, for example, connect to the RabbitMQ broker (using the given parameters, host name, port number, etc) or when you declare a queue or an exchange. There is a choice of libraries for almost every programming language.
Steps to follow when setting up a connection and publishing a message/consuming a message:
Sample code will be given in the part 2, starting with Part 2.1 - Ruby, followed by Part 2.2 - Node.js, and Part 2.3 Python, It is possible to have different programming languages on different parts of the system. The publisher could, for example, be written in node.js and the subscriber in Python.
Hope this article helped you get some understanding about RabbitMQ!
Please email us at email@example.com if you have any suggestions or feedback.