Welcome to LavinMQ for beginners! This article is the first in a series of LavinMQ and will take you through concepts of message queueing, steps to set up your own LavinMQ instance, and a relatable example of a working LavinMQ system to follow for yourself. The guide goes on to explain the steps to set up a connection and the basics of publishing/consuming messages from a queue.
What is LavinMQ?
LavinMQ is a message queueing software, also called a message broker. Developers can define queues in this message broker, a queue that applications can set up connections to, and transfer messages into. Messages in the queues can include any kind of information such as simple text or information about a process or task. LavinMQ, as queue management software, gives an organized, safe place for messages to wait until another application or part of the system can come along and consume them for processing.
A LavinMQ Example
LavinMQ is a message queue, where tasks wait until the appropriate resources can process them. By acting as the middleman in the web application shown in the example below, LavinMQ reduces resource-heavy processes to another party that has no other job than to manage them.
The example follows a web application that allows users to upload a profile picture. Once the image is uploaded the user can traditionally decide what part of the image they want to show, scale it up or down and move it around. When they are happy they hit save. Now the web application needs to take these instructions together with the image and send a request to the part of the system that is responsible for "Image Processing" - which usually includes downsizing and optimisation for the web.
The website handles the information, scales the image, and saves it in the new format. In the example, the entire scaling process will take several seconds. Let’s get started.
The user enters the scaling information in the web application interface. The web application responds with a notification about the received request, “Image Scaling In Progress”.
The application also creates a message that includes all the information the user entered plus the uploaded image. This message is then placed onto a queue defined in LavinMQ.
The basic architecture in a message queue environment is efficient and simple. Client applications, known as producers, create messages and deliver them to the message queue, also known as broker. Consumer applications connect to the message queue, subscribe to the messages, and process them. The software can be a producer, a consumer, or even both. Messages are organized in the same order as they enter the queue, and are available from the message queue until the consumer retrieves them.
Instead of being forced to perform processes on the spot and take up valuable resources, message queue architecture allows web servers to offload this work and instead respond to each request immediately. Message queues are also highly valuable for balancing of workloads.
Back to the example web application, where the consumer grabs a message from the queue that contains the image information and starts scaling the image. At the same time, the producer is able to queue up new requests from other users. The consumer can be on a totally different server than the producer - or not. The request can be created in one programming language and handled in another. The beauty of message queues is the uncoupled nature, allowing two applications to communicate through messages sent through the queue.
- The user sends an image scaling request to the web application
- The producer (the web application) sends a message to LavinMQ that includes the image data (current size, new size, user email, etc.)
- The exchange, which can be seen as a message routing agent, accepts the message from the producer and routes it to the correct queue
- The queue keeps the message until the consumer receives the task and starts processing the image
Message routing in LavinMQ - Exchanges
Messages are not published directly to a queue; instead, the producer sends messages via an exchange. An exchange is responsible for routing the messages to different queues with the help of bindings and routing keys. Bindings link queues and exchanges and routing keys are an attribute in the actual message that the exchange looks at when routing it to the proper queue.
More information about exchanges, bindings, and routing keys will be explored as the series continues. For now, let’s take a look at the message flow in LavinMQ so far:
- Producer publishes a message to the exchange
- The exchange receives the message and routes it according to the exchange type, routing key, etc.
- Two different bindings were created from the exchange to the queues during development. When routing, the exchange looks at the message attributes and routes them to the proper queue accordingly.
- Messages stay in the queue until the consumer handles them.
- The consumer handles the message.
A full exploration of the different exchange types, bindings, and routing keys will be shared in future installments of this tutorial of LavinMQ for beginners. For now, a brief definition of each exchange type will give plenty of information as we continue on with our example using a Direct exchange. The types are:
- Direct - The binding key in the message needs to have an exact match of the binding key between the queue and the exchange. For example, a queue is bound to an exchange using the binding key imagescaling. A message comes along with a routing key imagescaling and is therefore routed to that queue.
- Fanout - Routes messages to all queues bound to it.
- Topic - A wildcard match between routing keys and a routing pattern specified in the binding.
- Headers - The message contains header information that is used by the exchange for routing
Important LavinMQ (AMQP) Concepts
Before continuing this LavinMQ guide, let’s go over the important elements of the system and the concepts to understand so far:
The main concepts:
- Producer - sends the messages
- Consumer - receives the messages
- Queue - stores the messages
- Message - information
Other important concepts:
- Connection - between the application and LavinMQ
- Instance - An installation of LavinMQ on a server
- Cluster - a group of one or several nodes (servers)
- Channel - a virtual connection inside a connection
- Exchange - receives messages from producers and routes them to queues for the consumers based on the type of exchange (direct, fanout, topic, headers), the binding, and the routing key information
- Binding - a virtual link between a queue and an exchange
- Routing key - an address for messages that the exchange uses to determine queue routing
- AMQP (Advanced Message Queuing Protocol) - the protocol used by LavinMQ for messaging
- Vhost (Virtual Host) - virtual segregation/container within the server
In the image scaling web application example, there was one producer and one consumer. If the receiving application (the consumer) crashes or if the publisher sends a bunch of requests at once, messages would pile up in the queue until the consumer becomes active to process them one at a time.
Setting up a LavinMQ Instance
To continue following this tutorial of LavinMQ, it is recommended that you set up a LavinMQ instance or that you download and install LavinMQ. CloudAMQP is a hosted LavinMQ solution, so all you need to do is sign up for an account and create an instance and you’re on your way, no installation or server handling needed. Best of all CloudAMQP is free with the leming plan, so just click here, and let’s continue. You need to sign up as a user before you get started.
Select a datacenter and a region for your instance:
After your instance is created, click on the details to find your username, password, and connection URL for your cloud-hosted LavinMQ instance, as shown below:
Right from creation, the LavinMQ instance you created is ready to send messages across languages, platforms, and OSs. This decoupled system is highly scalable, resource-efficient, and includes a great management interface to control just about every aspect. Let us explore your LavinMQ server through the interface.
LavinMQ Management Interface
To provide a way to manage and monitor the LavinMQ instance, LavinMQ includes a web UI that is enabled by default in CloudAMQP. A link can be found on the details page for your LavinMQ instance. From the management interface, you can handle, create, delete, and/or list queues. You can also monitor queue length, check message rates, change and add user permissions, and many more vital tasks.
By default, LavinMQ uses a protocol called AMQP. To communicate, a client library to communicate with LavinMQ needs to be installed for the applications you intend to use with your instance. The client library is used when writing client applications and acts as an application programming interface (API). When communicating with LavinMQ, creating a queue or exchange, or connecting to the LavinMQ broker, the methods in the client library should be used. There is a choice of client libraries for almost every programming language.
To set up a connection and publish/consume a message:
- Set up/create a connection object, specifying the username, password, connection URL, port, etc. When calling the start method, a TCP connection is set up between the application and LavinMQ.
- Create a channel in the TCP connection.
- Declare/create a queue, which must be done before it can be used.
- Set up a exchange and bind the queue to an exchange. All exchanges must be declared and queues must be bound to an exchange before they can have messages routed to them.
- Publish a message to an exchange in Publisher; Consume the message from a queue in Subscriber/Consumer.
- Close the channel and the connection.
Are you eager to keep going with your LavinMQ education? That’s great - go on to Part 2 for example code used with Ruby, Node.js and Python. As we shared earlier in this tutorial of LavinMQ, the decoupled LavinMQ architecture allows different programming languages for different parts of the system. For example, a publisher writing in node.js and a subscriber using Python.
We hope you’re ready to continue learning about LavinMQ. Please email us if you have suggestions, questions, or other feedback!