Introduction
Configuration
Language Support
AMQP 0-9-1 Overview
More Exchange Types
More Consumer Features
Queue Deep-dive
Other Features
Reliable Message Delivery
High Availability
Monitoring
Management HTTP API
Tutorials
Networking
LavinMQ CLI
The Advanced Message Queuing Protocol (AMQP) Overview
What is the Advanced Message Queuing Protocol?
AMQP is a binary protocol, designed to handle large amounts of data and is typically the protocol that is used for message-oriented middleware. It allows messages to be sent asynchronously, meaning they don’t need to be processed immediately. LavinMQ supports all AMQP client libraries that are available for nearly every programming language.
Why is AMQP used in LavinMQ?
AMQP enables advanced messaging patterns like work queues, publish-subscribe, and routing, which make it an ideal choice for LavinMQ. It ensures reliable, asynchronous communication across different platforms, guarantees message delivery, and supports scalability, making it a trusted choice for building flexible and resilient messaging systems.
LavinMQ extends the open standard AMQP 0.9.1 specification. AMQP is one of two protocols supported by LavinMQ.
Main concepts in AMQP
In AMQP 0-9-1, producers send messages to an exchange. These messages are routed from the exchange to a queue based on exchange types and routing keys, forming the core structure of its messaging model. Consumers then retrieve messages from the queues.
Queues
A queue provides a place to store messages, acting as a buffer before they are consumed. Before use, a queue must be declared with a specified name or assigned a random one by the broker. During creation, queues can be configured with various attributes that define their lifecycle and behaviour. For example, an auto-delete queue is automatically removed when its last connection closes. In contrast, an exclusive queue can only be used by a single connection and is deleted when that connection ends.
Learn more about how to create a queue, q**ueue properties, and arguments.**
Exchange types and bindings
A message is routed to a queue depending on the exchange type and bindings between the exchange and the queue. For a queue to receive messages, it must be bound to at least one exchange. LavinMQ provides four main exchange types - direct exchange, fanout exchange, topic exchange, and header exchange.
During creation, an exchange can be declared with several attributes. For instance, it can be marked as durable to survive a broker restart, or it can be marked as auto-delete, meaning that it’s automatically deleted when the last queue is unbound. A binding is a relation between a queue and an exchange consisting of rules that the exchange uses (among other things) to route messages to queues.
Learn more about exchange types and bindings and how to create them.
Message and content
A message is a package sent from a publisher (sending client) to LavinMQ. Once LavinMQ receives it, the message is passed through an exchange, which decides where the message should go based on specific rules. The message is then stored in a queue, waiting to be picked up by a consumer (receiving client). Each message contains a set of headers, defining properties such as life duration, durability, and priority.
AMQP 0.9.1 includes a built-in message acknowledgment feature that confirms message delivery and processing.
Read more about messages.
Connections and channels
A connection is like a direct link between your application and LavinMQ over TCP/IP. Channels are like virtual pathways within that link, through which messages are actually sent and received. One connection can support multiple channels, allowing your application to send and receive multiple messages at once, without needing separate physical connections.
The documentation provides more information about connections and channels and their relationships.
Virtual Hosts
Think of virtual hosts (vhosts) as separate namespaces within LavinMQ where applications can run independently. Each vhost is like its own private area where queues and exchanges are created, and these resources don’t overlap with other vhosts. This separation helps control who can access what: users are given permission to specific vhosts, so they can only interact with the resources in their assigned space. This way, you can keep different applications isolated and secure within the same broker.
Learn more about vhosts.
Ready to take the next steps? Here are some things you should keep in mind:
Managed LavinMQ instance on CloudAMQP
LavinMQ has been built with performance and ease of use in mind - we've benchmarked a throughput of about 1,000,000 messages/sec. You can try LavinMQ without any installation hassle by creating a free instance on CloudAMQP. Signing up is a breeze.
Help and feedback
We welcome your feedback and are eager to address any questions you may have about this piece or using LavinMQ. Join our Slack channel to connect with us directly. You can also find LavinMQ on GitHub.