Exchanges & Queues
Messages are published to exchanges. Publishers only need to interact with them to deliver messages.
Messages are delivered to queues. Subscribers only need to interact with them to consume messages.
RabbitMQ binds exchanges to queues, decoupling receivers and consumers.
Message Routing
You have a lot of flexibility on routing messages (from exchanges to queues). The most straightforward one is the direct routing (which routes based on the given routing key), which can act as unicast or multicast:
Another useful one is the fanout (no routing key), which is pretty much a broadcast:
One Connection, Many Commands
Connection:
- It’s TCP-based and assumes long-lived connections for efficiency (a new connection is not opened per protocol operation).
- By default, RabbitMQ will listen on port 5672 on all available interfaces.
Channel:
- A lightweight connection that shares a single TCP connection (multiplexing).
- A channel only exists within a connection and never on its own.
- It is very common to open a new channel per thread and not share channels between them.
- A channel can be closed due to a protocol exception.
Virtual Hosts
Virtual hosts is loosely like a namespace:
- Has a name.
- Provides logical grouping and separation of resources.
- Are created and deleted using rabbitmqctl or the HTTP API (no need to edit a configuration file).
- Resource permissions in RabbitMQ are scope per virtual host.
AMQP 0.9.1
Counterintuitively, AMQP 1.0 is quite different from 0.9.1, sharing nothing at the wire level. Many of RabbitMQ’s core ideas, like exchanges and routing keys, only exist in 0.9.1.
Erlang
RabbitMQ is written in Erlang, which fits nicely with the problem it's tackling. Erlang applications are built of very lightweight (Erlang) processes that can be seen as “living” objects, with data encapsulation and message passing, but capable of changing behavior during runtime.
Mnesia vs Khepri
Mnesia is a distributed, soft real-time database management system included as part of Erlang’s standard library (Open Telecom Platform, OTP). It provides features such as atomic transactions, table replication, and a flexible schema, making it highly suitable for use cases demanding high availability and fault tolerance.
Khepri is a new storage backend for RabbitMQ metadata, designed to replace Mnesia. Built on the Raft protocol, it simplifies cluster management by automatically handling network partitions, similar to quorum queues, without requiring additional configuration.
Mnesia is the original storage of RabbitMQ and still the default as time of writing, despite the introduction of Khepri.
Web Interface
Rabbit offers a lovely web interface, that runs by default on, allowing directly on the web browser:
- Message publishing.
- Message consuming.
- Monitoring usage.
- Basic server statistics.
If you are running it locally, you can access on http://localhost:15672 and use guest
as both username and password.
Permissions
- An user has configure, write, and read permissions.
- Configure: create, destroy, or alter resources (exchanges and queues).
- Write: message publishing.
- Read: message consuming.
- Permissions are a regex, “^foo” gives permission on resources with names initiated by “foo”.
- Permissions are per virtual host.
Some Useful Commands
sudo service rabbitmq-server status
sudo rabbitmq-plugins enable rabbitmq-management
sudo service rabbitmq-server restart
sudo rabbitmqctl add_user ccm-admin hare123
sudo rabbitmqctl set_user_tags ccm-admin administrator
sudo rabbitmqctl add_vhost ccm_dev_vhost
sudo rabbitmqctl set_permissions -p ccm-dev-host ccm-admin ".*" ".*" ".*"
Top comments (0)