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
AMQP Virtual Hosts (vhosts)
A virtual host (vhost) is a uniquely named container inside LavinMQ. Inside each vhost container is a logical group of exchanges, connections, queues, bindings, user permissions, and other system resources. Different users can have different permissions to different vhost and queues and exchanges can be created, so they only exist in one vhost.
What is a vhost?
A vhosts in LavinMQ provides a way to segregate applications using the same LavinMQ server.
What benefits do a vhost have?
LavinMQ’s vhosts create a logical group of connections, exchanges, queues, bindings, user permissions, etc. within the server.
How can I use vhost?
Vhosts make it possible to separate applications on one broker. You can isolate users, exchanges, queues, and more to one specific vhost. You can separate environments, e.g. production to one vhost and staging to another vhost, within the same server instead of setting up multiple LavinMQ servers.
##Vhosts When a client establishes a connection to the LavinMQ server, it specifies the vhost within which it will operate:
amqp://myuser:mypassword@localhost:5672/myvhost
Resources such as exchanges and queues are named resources inside the vhost container, making each vhost essentially an LavinMQ mini-server. When configuring LavinMQ, at least one vhost is needed, which in default is named a slash “/”.
Vhosts can be created through the management portal or through the HTTP API, or via lavinmqctl. View vhosts by entering the admin tab and select the Virtual Hosts. Select the Add New Virtual Host options to create a new vhost.
The permissions within the vhost and the users assigned to it depend on your system requirements, and it’s up to you to assign users to the vhost. A newly created vhost always has a default set of exchanges, but no other entities and no user permissions.
Vhosts do not share exchanges or queues between them, and users, policies, etc. are unique to each vhost. Essentially, LavinMQ vhosts are like a virtual machine for a physical server, allowing for multiple secure application operations through virtual rather than physical separation. As the separation is virtual, it is important to remember that the vhosts are not physically separated from each other and therefore they might affect each other’s performance.
The same broker can be used on parts of different applications. Separate environments can be created, for example, production to one vhost and staging to another within the same broker rather than setting up multiple servers. The downside of using a single instance is that there’s no resource isolation between vhosts.
If one service is experiencing a traffic spike or a code bug, this may cause problems for other services and affect their performance. A vhost can be created for each service to hold all of the logical infrastructure, which also allows for better individual topology management.
vhost storage
Each vhost is backed by a message store on disk in a series of files (segments). Each incoming message is appended to the last segment, prefixed with a timestamp, its exchange name, routing key, and message headers.
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.