Reasons for using clusters

We started by showing you how to install and run the RabbitMQ service, but these are stand-alone versions that are not suitable for real-world applications. What if the RabbitMQ server experiences a memory crash, machine power failure, or motherboard failure? A single RabbitMQ server can handle 1000 messages per second. What if your application needs RabbitMQ service to handle 100,000 messages per second? Buying expensive servers to boost the performance of stand-alone RabbitMQ services is not enough. Building a RabbitMQ cluster is the key to solving the problem.

Set up the RabbitMQ cluster

  • If you have the first RabbitMQ machine with VM ware, clone two more machines.

  • Example Change the host names of the three machines

vim /etc/hostname

Set the names of the three machines to node1, node2, and node3, and restart the machines.

  • Configure the hosts file for each node so that each node can identify itself

Vim/etc/hosts 192.168.37.139 node1

192.168.37.140 2 192.168.37.141 node3

  • To ensure that the cookie files of each node use the same value, run the remote operation command on node1

scp /var/lib/rabbitmq/.erlang.cookie root@node2:/var/lib/rabbitmq/.erlang.cookie

scp /var/lib/rabbitmq/.erlang.cookie root@node3:/var/lib/rabbitmq/.erlang.cookie

  • Start the RabbitMQ service, along with the Erlang virtual machine and RbbitMQ application service (run the following command on each of the three nodes)

rabbitmq-server -detached

  • Perform this operation on node 2

rabbitmqctl stop_app

Rabbitmqctl stop will shut down the Erlang virtual machine Rabbitmqctl stop_app Stops only the RabbitMQ service.) rabbitmqctl reset rabbitmqctl join_cluster rabbit@node1 rabbitmqctl Start_app (start application service only)

  • Perform this operation on node 3

rabbitmqctl stop_app

rabbitmqctl reset rabbitmqctl join_cluster rabbit@node2 rabbitmqctl start_app

  • State of the cluster

rabbitmqctl cluster_status

  • You need to reset the user (on either machine)

Create account

Rabbitmqctl add_user admin 123456 Set the user role rabbitmqctl set_user_tags admin administrator Set the user permission rabbitmqctl set_permissions -p “/” admin “.” “.” “.*”

  • Uncluster nodes (node2 and Node3 machines respectively)

rabbitmqctl stop_app

rabbitmqctl reset rabbitmqctl start_app rabbitmqctl cluster_status rabbitmqctl forget_cluster_node rabbit@node2(node1 Execution on machine)

Mirrored queue

The mirror queue is used

If there is only one Broker node in the RabbitMQ cluster, the failure of this node will result in the temporary unavailability of the entire service and may result in the loss of messages. All messages can be durable and the durable attribute of the queue is set to true, but there is still a problem with caching because there is a short but problematic time window between when a message is sent and when it is written to a disk well for brushing. Although the publisherConfirm mechanism ensures that the client knows what messages have been saved to disk, it is generally undesirable to encounter service unavailability due to a single point of failure. A Mirror Queue is introduced to Mirror the Queue to other Broker nodes in the cluster. If a node in the cluster fails, the Queue can be automatically switched to another node in the Mirror to ensure service availability.

Set up steps

  • Start the nodes under the three clusters.
  • Add a policy to any node.

  • Create a queue on node1 to send a message. The queue has mirror queues

  • After node1 is stopped, node2 becomes a mirrored queue

  • Even if only one machine is left in the cluster, the message in the queue can still be consumed, indicating that the message in the queue is transferred to the corresponding machine in the mirror queue.