preface

This article provides a systematic introduction to the RabbitMQ cluster architecture features, exception handling, setup and use of some of the details to pay attention to.

knowledge

Why cluster?

Second, the characteristics of clusters

3. Cluster exception handling

4. Cluster node type

5. Cluster building method

6. Mirror queue

Why cluster?

Built – in clustering is one of RabbitMQ’s best features. It does two things:

  1. [Fixed] Allow consumers and producers to continue operating in the event of a Rabbit node crash
  2. Expand Rabbit to handle more messages and carry more traffic by adding nodes;

Second, the characteristics of clusters

RabbitMQ clusters are made up of multiple nodes, but we found that not every node has a full copy of all the queues.

Incomplete copy feature of RabbitMQ nodes

Why does RabbitMQ not copy all queue content and state to all nodes by default?

There are two reasons:

  1. Storage space – If each node has a full copy of all queues, the new node does not add storage space, but more redundant data.
  2. Performance – If messages are safely copied to each node in the cluster, then the new nodes will increase the network and disk load. This will defeat the original purpose of the cluster. The new nodes will not improve the ability to process messages, but will maintain the same or worse performance as the single node.

So all the other non-owner nodes know is the metadata of the queue and the pointer to the queue node.

3. Cluster exception handling

When a cluster node crashes, the node queue and its associated bindings are lost. Consumers attached to the queue lose their subscription information. How to deal with this problem?

This question falls into two categories:

  1. The message has been persisted, so when the node is restored, the message is also restored;
  2. If the message is not persistent, you can use the hypermetro redundant queue described below to ensure message reliability.

4. Cluster node type

The storage types of nodes are as follows:

  • Disk node
  • The memory node

Disk nodes store configuration information and meta-information on disks, while secondary nodes store this information in memory. Of course, the performance of secondary nodes is much better than that of disk nodes.

Single-node systems must be disk nodes, otherwise all system configuration information will be lost every time you restart RabbitMQ.

RabbitMQ requires that there be at least one disk node in the cluster and the disk node must be notified when a node joins or leaves the cluster.

Special exception: The only disk node in the cluster crashes

What happens if the only disk node in the cluster crashes as a result?

If the disk node with the only disk crashes, the following operations cannot be performed:

  • Unable to create queue
  • Unable to create a switch
  • Unable to create binding
  • Cannot add user
  • Permissions cannot be changed
  • Several points cannot be added and removed from the cluster

Summary: If the disk node with the only disk crashes, the cluster can keep running, but you can’t change anything.

Solution: Set up two disk nodes in the cluster, as long as one is ok, you can operate normally.

5. Cluster building method

In this chapter, we use Docker to create RabbitMQ clusters. First, it is easy to operate, second, it can make full use of the hardware resources of the server, and third, Docker is now the mainstream deployment scheme. For more details, you can see my other article: Deploying RabbitMQ clusters with Docker next, we have two steps to set up a cluster:

  • Step 1: Install multiple RabbitMQ nodes
  • Step 2: Add the RabbitMQ node to the cluster

Step 1: Install multiple RabbitMQ nodes

docker run -d --hostname rabbit1 --name myrabbit1 -p 15672:15672 -p 5672:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie'The rabbitmq: 3.6.15 - management docker run-d --hostname rabbit2 --name myrabbit2 -p 5673:5672 --link myrabbit1:rabbit1 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie'The rabbitmq: 3.6.15 - management docker run-d --hostname rabbit3 --name myrabbit3 -p 5674:5672 --link myrabbit1:rabbit1 --link myrabbit2:rabbit2 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie'The rabbitmq: 3.6.15 - managementCopy the code

For details about the parameters, see Starting RabbitMQ.

Note:

  1. Use “–link” to connect multiple containers. This attribute cannot be less.
  2. The Erlang Cookie values must be the same, that is, the RABBITMQ_ERLANG_COOKIE values must be the same, for the reasons described in the “Configure the same Erlang Cookie” section below.

Step 2: Add the RabbitMQ node to the cluster

Set controller 1:

docker exec -it myrabbit1 bash rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl start_app exit

Add node 2 to the cluster:

docker exec -it myrabbit2 bash rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster –ram rabbit@rabbit1 rabbitmqctl start_app exit

The –ram parameter indicates that the memory node is set to a memory node. If the secondary parameter is omitted, the disk node is set to a disk node by default.

Add node 3 to the cluster:

docker exec -it myrabbit3 bash rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster –ram rabbit@rabbit1 rabbitmqctl start_app exit

The default password is guest/guest. The result is shown in the following figure:

So far we have set up the RabbitMQ cluster and started 3 nodes, 1 disk node and 2 memory nodes.

Setting the Node Type

If you want to change the node type, you can run the following command to change it:

rabbitmqctl stop_app

rabbitmqctl change_cluster_node_type dist

rabbitmqctl change_cluster_node_type ram

rabbitmqctl start_app

Remove node

To remove a node from the cluster, run the following command:

rabbitmqctl stop_app

rabbitmqctl restart

rabbitmqctl start_app

Cluster Restart Sequence

The sequence of cluster restarts is fixed and reversed. As follows:

  • Boot sequence: Disk nodes => Memory nodes
  • Shutdown sequence: Memory nodes => Disk nodes

The disk node must be shut down. Otherwise, exceptions such as cluster startup failure and data loss may occur.

6. Mirror queue

Mirror queue is a new feature with Rabbit2.6.0 that allows built-in redundancy for hypermetro. Unlike normal queues, mirror nodes in the cluster have a copy of the slave queue. If the primary node is unavailable, the oldest slave queue is elected as the new primary queue.

How mirrored queues work: You can think of mirrored queues, to some extent, as having a hidden FANout exchange that instructs the channel to distribute messages to slave queues.

Setting a Mirror Queue

Rabbitmqctl set_policy name match pattern (regular) mirror definition command, for example, to set a mirror queue named mypolicy and match all queues with names starting with AMP stored on 2 nodes as follows:

rabbitmqctl set_policy mypolicy “^amp*” ‘{“ha-mode”:”exactly”,”ha-params”:2}’

You can see that there are three parameters for setting up the mirror queue, each separated by a space.

  1. Parameter 1: Name, which can be filled freely.
  2. Parameter 2: Matching rule of queue name, expressed by regular expression.
  3. Parameter 3: as the main body in the mirror of the queue rules, is a json string, divided into three attributes: ha – mode | ha – params | ha – sync – mode, explain respectively as follows:
  • Ha-mode: mirroring mode. Classification: all/ Exactly/Nodes, all Is stored on all nodes. Exactly stores X exactly number of nodes specified by ha-Params; Nodes Specifies the name of the storage node. Use the ha-params command.
  • Ha-params: as a parameter, supplementary to ha-mode;
  • Ha-sync-mode: mirror message synchronization mode: automatic (automatic), manually (manual).

The effect of setting the mirror queue to store two nodes is shown as follows:

Viewing a Mirror Queue

rabbitmqctl list_policies

Deleting a Mirror Queue

rabbitmqctl clear_policy

The resources

Book: RabbitMQ In Action – Efficient Deployment of distributed message queues – not recommended, www.cnblogs.com/luo-mao/p/5… www.jianshu.com/p/85543491a…

Long click on the QR code to pay more attention to the author