MESSAGE QUEUE & PUB-SUB
Messaging solutions simplify development of application by giving architects and
developers a standardized, reusable component for robustly handling the flow of
data so that they can focus on the core logic in their applications.
The two primary messaging models are message queuing and publish-subscribe
(often referred to as pub-sub) messaging.
RabbitMQ (Message broker):
It accepts and forwards messages. A message broker acts as an intermediary
platform when it comes to processing communication between two applications.
Scenario :
Suppose you own a restaurant. Now imagine the situation where users are
placing the order simultaneously and the backend servers are not processing the
orders as fast as they should, or some backend error has occurred or hardware
is malfunctioned. Since all the requests were directly handled by the server,
these requests will not be processed.
Now let’s see how RabbitMQ can resolve this:
We can place a service in between the two services, i.e front-end and backend.
That service is Rabbit. It will consume all messages from the front-end and will
only release when the backend is ready to process it.
Message brokers do many things such as:
A message queue provides an asynchronous communications protocol.
You have the option to send a message from one service to another
without having to know if another service is able to handle it immediately or not.
Messages can wait until the responsible service is ready. A service
publishing a message does not need to know anything about the inner workings
of the services that will process that message.
Store the messages
Routing of messages
Monitoring and management of messages
Let’s understand a few terms first:
Producer: A program that sends messages.
Consumer: A program that receives messages.
Channel: A channel is a virtual connection inside a connection. When you are
publishing or consuming messages from a queue — it’s all done over a channel.
Connection: A connection is a TCP connection between your application and
the RabbitMQ broker.
Routing Key: Routing keybinding with the queue are ruled that allow the
exchange to put messages into the queue.
Exchange: The exchange receives messages from the producer and from the
other side it pushes them to the queues. The exchange must know exactly what
to do with the messages it receives. Should it be appended to a particular
queue? Should it be appended to many queues? Or should it get discarded? The
rules for determining that are defined by the exchange type.
There are mainly four type of exchanges available:
1. Direct: Sends a message to the queue whose binding key matches.
2. Topic: Sends the message on basis of the pattern.
3. Headers: A headers exchange is an exchange which routes messages to
queues based on message header values instead of routing key.
4. Fanout: Sends a message to all the queues.
The producer creates a message and sends (publishes) into the message broker
(RabbitMQ). A message must have two parts: a payload and a label(routing key). The
payload is data and it can be anything from a simple JSON to MPEG-4 file.
Each queue is bound to a routing key or a pattern of routing keys. This routing
keybinding with the queue is ruled that allow the exchange to put messages into the
queue. The label describes the payload and how RabbitMQ will determine who should
get a copy of the message.
The communication between publisher and RabbitMQ is one directional and fire and
forget. The consumer, on the other hand, attaches to the broker and subscribes to a
queue to get the message.
Publish-Subscribe Messaging
Like message queuing, publish-subscribe messaging moves information from senders
to consumers.
However, in contrast to message queuing, publish-subscribe messaging allows multiple
consumers to receive each message in a topic.
Further, pub-sub messaging ensures that each consumer receives messages in a topic
in the exact order in which they were received by the messaging system.