RabbitMQ Introduction:
RabbitMQ as the name denotes its the Message-Queuing system also known as a message broker or queue manager. To simplify the definition, it is a piece of software where queues are defined & configured, applications connect to these queues to publish or consume a message or multiple messages.
A message can vary from a simple text message, binary information to the information about an individual process that can even be running on a different server.
Queues majorly work on the consumer & producer model, having said that, a message can be published to the queue (a.k.a producer) to process by a receiving application (a.k.a consumer). The queue-manager software retains the messages in the system until a consumer consumes the message & process it.
To put them all together, a message broker can be defined as a middle-man that retains multiple messages produced by applications, to process at the consumer end, depending on the availability of producers & consumers.
For example: Consider having 5 producers, each producing 1 message every second & there are only 3consumers where each can consume only 1 message every second. In this scenario, the other 2messages would go unprocessed by the consumers. Here comes the middle-man message-broker that stores all the messages produced by the producers & helps the consumer to consume the same based on the availability. This makes sure that no messages are lost during the process. Also, queues by default follow the first in-first out strategy so that all messages are processed seamlessly.
RabbitMQ(RMQ) Cluster Mode:
A RabbitMQ cluster is a logical grouping of one or several nodes, each sharing users, virtual hosts, queues, exchanges, bindings, runtime parameters, and other distributed state. For the high availability of the rabbitMQ queues, the infra should be highly available. This is accomplished by creating a minimum of 3 node RMQ cluster. A minimum of 3 nodes is suggested to retain quorum among the servers.
Unlike other cluster models, RMQ cluster doesn’t segregate any node as master & slave. All RabbitMQ brokers when started initially, start out as running on a single node. Preferably, these nodes could be joined into clusters, and subsequently turned back into individual brokers again. All data/state required for the operation of a RabbitMQ broker is replicated across all nodes. An exception to this is message queues, which by default reside on one node, though they are visible and reachable from all nodes.
Downloading & Installing RabbitMQ can be followed at the official RMQ site:
Step I: RabbitMQ cluster creation:
Considering we have 3 nodes for the RabbitMQ cluster, with RMQ version 3.8.3. Naming the nodes as Node1, Node2, Node3 for our reference. The nodes within an RMQ cluster should be able to resolve each other with their domain names, either short or fully-qualified (FQDNs). Every node of the RMQ cluster must resolve the hostnames of all cluster members from each cluster node.
Let’s start all the rabbitMQ servers separately & then combine them to form a cluster.
On all nodes:
- To ensure rabbitMQ is running in all 3 nodes, restart the service with below command:
sudo service rabbitmq-server restart - Enable rabbitMQ-server service via chkconfig:
sudo chkconfig rabbitmq-server on - Verify the rabbit-server service is running on all the three nodes (node1,2&3) by checking the status:
sudo rabbitmqctl statusThe output of rabbitmqctl status:
