RabbitMQ

=> Is a message broker, accepts and forwards messages.

• Producer: application that sends messages.

• Queue: is a large message buffer that stores messages. Many producers can send messages that go to one queue, and many consumers can receive data from one queue.

• Consumer: application that receives messages.

• Round-Robin: Send message to the next consumer, in sequence.

Message acknowledgment

• ack (nowledgment): is sent back by the consumer to tell rabbit that a particular message has been received, processed and that rabbit is free to delete it.

Message durability

When rabbit quits or crashes it will forget the queue and messages unless you tell it not do. Two things are required to make sure that messages aren't lost: we need to mark both the queue and messages as durable.

Fair dispatch

Dispatching still doesn't work exactly as we want. RabbitMQ just dispatches a message when the message enters the queue. It doesn't look at the number of unacknowledged messages for a consumer. In order to defeat that we can use the prefetch method with the value of 1. This tells RabbitMQ not to give more than one message to a worker at a time.

channel.prefetch(1);

Exchanges

The core idea in the messaging model in RabbitMQ is that the producer never sends any messages directly to a queue. Instead, the producer can only send messages to an exchange. An exchange is a very simple thing. On one side it receives messages from producers and the other side it pushes them to queues.

There are a few exchange types available: direct, topic, headers and fanout.

• fanout: broadcasts all the messages it receives to all the queues it knows. Routing key value is ignored.

• direct: The routing algorithm behind a direct exchange is simple - a message goes to the queues whose binding key exactly matches the routing key of the message.

• topic: Messages sent to a topic exchange can't have an arbitrary routing key - it must be a list of words, delimited by dots. The words can be anything, but usually they specify some features connected to the message. The binding key must also be in the same form. The logic behind the topic exchange is similar to a direct one - a message sent with a particular routing key will be delivered to all the queues that are bound with a matching binding key. However there are two important special cases for binding keys:

  • * (star) can substitute for exactly one word.
  • # (hash) can substitute for zero or more words.

  

Bindings

That relationship between exchange and a queue is called a binding. This can be simply read as: the queue is interested in messages from this exchange. Bindings can take an extra binding key parameter.

channel.bindQueue(queue_name, exchange_name, 'key');

Multiple bindings

It is perfectly legal to bind multiple queues with the same binding key.

RPC (Remote Procedure Call)

A client sends a request message and a server replies with a response message.

Callback queue

In order to receive a response we need to send a 'callback' queue address with the request.

  channel.sendToQueue('rpc_queue', Buffer.from('10'), {
    replyTo: queue_name
  });

Message properties

• persistent: Marks a message as persistent (with a value of true) or transient (false)
• content_type: Used to describe the mime-type of the encoding. For example for the often used JSON encoding it is a good practice to set this property to: application/json.
• reply_to: Commonly used to name a callback queue.
• correlation_id: Useful to correlate RPC responses with requests. Unique value for every request. Later, when we receive a message in the callback queue we'll look at this property, and based on that we'll be able to match a response with a request. If we see an unknown correlation_id value, we may safely discard the message - it doesn't belong to our requests.

Summary

Our RPC will work like this:

• When the Client starts up, it creates an anonymous exclusive callback queue.
• For an RPC request, the Client sends a message with two properties: reply_to, which is set to the callback queue and correlation_id, which is set to a unique value for every request.
• The request is sent to an rpc_queue queue. The RPC worker (aka: server) is waiting for requests on that queue. When a request appears, it does the job and sends a message with the result back to the Client, using the queue from the reply_to field.
• The client waits for data on the callback queue. When a message appears, it checks the correlation_id property. If it matches the value from the request it returns the response to the application.