Scribd
Upload
100 views5 pages

RabbitMQ Urbiotica

RabbitMQ is a message broker that transports messages from publishers to consumers. It uses exchanges to route messages to queues based on bindings and routing keys. Publishers send messages to exchanges, which then route the messages to queues based on the binding rules. Consumers consume messages from queues. Messages contain attributes and a payload. There are different types of exchanges like direct, topic, and headers exchanges that route messages differently based on routing keys or message headers. Queues store messages and have configuration options like being durable or auto-deleted. Consumers retrieve messages from queues, process them, and acknowledge or negatively acknowledge them.

Uploaded by

zouinekh samar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100 views5 pages

RabbitMQ Urbiotica

RabbitMQ is a message broker that transports messages from publishers to consumers. It uses exchanges to route messages to queues based on bindings and routing keys. Publishers send messages to exchanges, which then route the messages to queues based on the binding rules. Consumers consume messages from queues. Messages contain attributes and a payload. There are different types of exchanges like direct, topic, and headers exchanges that route messages differently based on routing keys or message headers. Queues store messages and have configuration options like being durable or auto-deleted. Consumers retrieve messages from queues, process them, and acknowledge or negatively acknowledge them.

Uploaded by

zouinekh samar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Urbiotica

counting API

RABBITMQ
RabbitMQ is a message broker, its role is to transport and
route messages from publishers to consumers.
The broker uses the exchanges and bindings to know whether
or not to deliver the message in the queue.

Here is the overall operation of the broker:


The publisher will send a message to an exchange which
will, depending on the binding, route the message to the
queue(s). Then a consumer will consume the messages.
THE MESSAGE

The message is like an HTTP request, it contains attributes and a


payload.

THE BINDINGS

Bindings are the rules that exchanges use to determine which queue
to deliver the message to. The different configurations can use the
routing key (direct/topic exchanges) as well as the headers (header
exchanges). In the case of fanout exchanges, the queues only have to
be binded to receive the message.

THE EXCHANGES

An exchange is a message router. There are different types of routing


defined by the type of exchange.

You publish to an exchange. You do not consume an exchange!

The amq.default exchange is the default rabbit exchange. You


can't delete it or bind to it.
This exchange is auto-binded with all queues with a routing key
equal to the queue name.
The fanout exchange is the simplest. Indeed it delivers the
message to all the blinded cues.

The direct exchange only allows binding using strictly the routing
key.
If the routing_key of the message is strictly equal to the
routing_key specified in the binding then the message will be
delivered to the queue.

BINDING.ROUTING_KEY == MESSAGE.ROUTING_KEY
The Topic Exchange delivers the message if the routing_key of
the message matches the pattern defined in the binding.

MATCH(BINDING.ROUTING_KEY, MESSAGE.ROUTING_KEY)

The Headers Exchange deliver the message if the binding


headers match the message headers.
THE QUEUES

A queue is the place where messages are stored. There are


configuration options to change their behavior.
Some options:
Durable, (stored on disk) the queue will survive the restart of the
broker. Be careful, only persistent messages will survive the
reboot.
Exclusive, will be usable on a single connection and will be
deleted when the connection is closed.
Auto-delete, the queue will be deleted when all connections are
closed (after at least one connection).

Vous publiez dans un exchange. Vous ne consommez pas un


exchange ! (quand vous croyez publier dans une queue en
réalité le message est publié dans l’exchange amq.default avec
la routing key = queue name)

CONSUMER

The role of the consumer is to execute a treatment after having


retrieved one or more messages.

To do this it will prefetch one or more messages from the queue,


before executing a process. Generally if the processing has been
successful the consumer will acknowledge the message successfully
(basic.ack). In case of an error the consumer can also negatively
acknowledge the message (basic.nack). If the message is not
acknowledged, it will remain in its place in the queue and will be
fetched again later.

You might also like