An overview of the

AMQP 0-9-1 and AMQP 1.0 and other messaging protocols that RabbitMQ supports through plug-ins are inherently distributed: applications almost always connect to RabbitMQ from a remote host. Building distributed RabbitMQ is usually necessary or desirable. There are three ways to do this: 1) Use clusters; 2) Use Federation plugin; 3) Use the Shovel. This guide provides an overview of each approach.

Note: these three methods are not mutually exclusive and can be used in combination: clusters can be connected to Federation, the Shovel, or both.

The cluster

Clustering connects multiple machines together to form a cluster. Communication between nodes is transparent to the client. The design of the cluster assumes that the network connection is fairly reliable and provides lAN-like latency.

1) All nodes in the cluster must run compatible RabbitMQ and Erlang versions; 2) Nodes authenticate each other by using pre-shared keys (Erlang cookies) installed by automated deployment tools;

Virtual hosts, switches, users, and permissions are automatically replicated between all nodes in the cluster. Queues can be on a single node or mirrored across multiple nodes. Clients connected to any node in the cluster can use all non-exclusive queues in the cluster, even if they are not on that node.

Federation plug-in

The Federation plugin allows one broker’s switch or queue to receive messages from an exchange or queue published to another broker, which can be a single machine or a cluster. Communication is through AMQP (with optional SSL), so the two switches or queues must be granted the appropriate users and permissions to be federated.

1) The joint switch is connected through point-to-point links. By default, messages will only be forwarded once on federated links, but this capability can be added (via more complex federated switches) to support more complex routing topologies. Some messages may not be transmitted over the link; If a message is not routed to a queue after it arrives at the federation exchange, it is not forwarded in the first place; 2) Federated queues are similarly connected via point-to-point links. Messages will be moved between the federated queues any number of times to track the consumer;

Typically, you would use Federation to link message brokers on the Internet for publish/subscribe messaging and work queuing.

Shovel plug-in

Connecting to a message broker using the Shovel is similar to using Federation. The Shovel, however, works at a lower level.

The purpose of the Federation plugin is to provide custom distribution of switches and queues; The Shovel simply consumes messages from one broker and forwards them to another broker’s switch.

Generally, when you need more control from the Federation plug-in, you can use the Shovel plug-in to connect to message brokers on the network. The dynamic Shovel can be useful when moving messages in a specific way.

conclusion

Distributed RabbitMQ (cluster)