Internal Errigal Collaboration Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== RabbitMQ ======
Author : Colm Carew
\\ Date : 2017-01-31
===== What is RabbitMQ =====
RabbitMQ is a middleware component that facilitates messaging between applications and processes via the Advanced Message Queuing Protocol (AMQP).

Basically it facilitates communication of applications with queues.

This allows separation of concerns and decoupling of applications.

There are some very good tutorials on RabbitMQ which can be found : [[https://www.rabbitmq.com/getstarted.html]]

If you would like to install RabbitMQ, If on a local machine I would recommend using Docker, else if installing on RedHadt Rehl6.6 the following link has details on how to do that : [[toolsandtechnologies:rabbitmq_and_rehl|How to Install RabbitMQ]]
===== What are Queues =====
Queues are used for IPC (Inter-Process Communication). IPC is basically the sharing of data/messages between applications/processes/threads.

Queues can be thought of a lot like a real life queues such as in a bank, in that there may be 10 people in a queue and 2 tellers working. Each teller can assist one person at a time while the other people wait until the teller is ready to assist them.
In software however, a process which takes messages off of a queue (similar to the bank teller) is called a consumer or queue consumer. A message stays on the queue until a consumer is ready to process the message.

UI : [[development:applications:ebonding:howto:rabbitmqgui]| RabbitMQ UI]]

===== Why Do We Need It =====
The reason we need RabbitMQ (or rather a queuing mechanism) is the ability to decouple applications from one another.

This comes with many benefits one of which is the promotion of Microservice Architecture.

For applications to thrive and be useful they usually need to talk to one another. Imagine 2 Applications. 1 is a Transmitter and the other is a Receiver. 

Without Queues, if the transmitter wanted to send something to the receiver, the receiver must be ready to receive the message and the Transmitter must know about the receiver (tightly coupled). In this case either the Transmitter waits until the Receiver is ready to receive the message or the Receiver buffers incoming messages. The issue with buffering is that if the application goes down then all items in the buffer are lost. A good goal in software is to design for failure and have a recovery strategy. In this case here the Transmitter and Receiver know about one another (which is tightly coupling and not good) and if the Receiver goes down what happens to the Transmitter? How many messages can it hold until the Receiver comes back online? What if a second Receiver is spun up, how do we distribute the messages?

These are all important questions that must be answered when designing a robust application suite.

If we take the case where we use queues. We still have the Transmitter and the Receiver applications however, if a Transmitter sends a message it places it on a queue and when the Receiver is ready it pulls messages off a queue. Each application does not know about one another, they know about a queue but not one another so if say the Receiver was replaced with a different application that consumes the queue then the Transmitter would not need to know about it as it knows nothing about the receiver only the queue. Now say that there is a high volume of messages coming in and the Receiver cannot process them fast enough. If we spin up another receiver and point it at the same queue the messages will be evenly distributed between the two receivers thus balancing the load. Also since the Transmitter does not have to wait to send a message to a queue, it can just send it to the queue and the message will be processed whenever a receiver gets it, the Transmitter doesn't care.


===== Exchanges =====
In RabbitMQ an Exchange is a way of distributing messages to queue/s. In supports the Publish/Subscribe Model if you are familiar with that. With exchanges, messages published to an exchanged are tagged with a routing key and then queues can be bound to the exchange via the routing key. A queue can have multiple bindings to an exchange.

With queues, a message will only ever be sent from the queue to one consumer. With exchanges however a message can be sent to multiple queues. In general a Producer (i.e. the Transmitter) will more often send messages to an exchange rather than a queue. The Receiver then decides how it's queue binds to an exchange and as a result what type of messages it's queue will get.

===== Prometheus =====
[[https://github.com/deadtrickster/prometheus_rabbitmq_exporter|This plugin]] will expose metrics for Prometheus.


===== Troubleshooting RabbitMQ =====

===== rabbit is failing to restart even with space cleared out =====

seeing the following error when running rabbitmqctl status Error:
{:aborted, {:no_exists, [:rabbit_vhost, [{{:vhost, :"$1", :_, :_}, [], [:"$1"]}]]}}

it appears that error means the mnesis database was corrupted. I have had to clear out the dir: sudo rm -rf /var/lib/rabbitmq/mnesia/

It has restarted now, but I think it may need to be rebuilt in terms of users / vhosts, just checking now
Sidebar

Internal Errigal Collaboration Wiki

User Tools

Site Tools

Page Tools
