RabbitMQ: Basic

Jul 23, 2022

—

Producer (Publisher)

Service that wants to send messages.

Message

Persistence is a property of messages. To mark a message as persistent, set its delivery mode to 2. AMQP brokers handles persistent messages by writing them to disk inside a special persistency log file, allowing them to be restored in the event of server restart. Notice that persistent message has no effect inside a non-durable queue; When the server restarts, the queue will not be recreated and thus the messages will not be recreated from the persistency log file. This is also true for every non-durable queue that the message may be routed to: Once a message is routed to a non-durable queue it gets deleted from the persistency log file and is not considered persistent anymore. The persistency log file gets cleaned periodically by garbage collection. Persistent messages are marked for garbage collection once they are consumed (and acknowledged) from a durable queue.
https://asafdav2.github.io/2017/rabbit-mq-persistentcy-vs-durability/

Message Properties: https://www.rabbitmq.com/consumers.html#message-properties

Exchange

Publishing to the exchange will forward the message to the queue, if there are no queue bind to the exchange, then the message is lost.

Queue

This is where the message live.

Queue properties: https://www.rabbitmq.com/queues.html#properties

Durable (the queue will survive a broker restart)

Making a queue durable is not the same as making the messages on it persistent. Messages can be published either having a delivery mode set to persistent or transient. You need to set delivery mode to persistent when publishing your message, if you would like it to remain in your durable queue during restart.
https://www.cloudamqp.com/blog/how-to-persist-messages-during-RabbitMQ-broker-restart.html

https://peterdaugaardrasmussen.com/2018/07/25/rabbitmq-what-is-the-difference-between-persistent-and-durable/

Exclusive (used by only one connection and the queue will be deleted when that connection closes)

Auto-delete (queue that has had at least one consumer is deleted when last consumer unsubscribes)

Consumer (Worker)

Service that processes message(s)

Auto Ack

TRUE – Server will automatically acknowledge that message(s) are sent successfully and to be taken out from the queue.

FALSE – Server will wait for acknowledgement of the delivery of message(s). The delivery will be kept until the worker send Ack manually.

QoS

If no worker is connected, then by default server will send all queued messages to the first connected worker. We can control this behavior by setting the QoS.

This only works only Auto Ack is set to FALSE.

Prefetch Count – This is the number of messages at a time to be delivered to the worker.

Prefetch Size – This is the number of bytes that the server will try to keep flushed to the network before receiving acknowledgments from the consumers.

Global – when this flag is TRUE, these QoS settings apply to all existing and future consumers on all channels on the same connection.

When this flag is set to FALSE, the settings will apply to all existing and future consumers on this channel.

Channel

What? Why TCP connection is not sufficient? Why do we need the channel? Let’s say, you don’t have a channel. In multi threading architecture you may need a separate connection per thread. That may leads to under utilization of TCP connection, also it adds overhead to the operating system to establish as many TCP connection it requires during peak time of the network. Performance of the system could be drastically reduce. This is where the channel comes handy, it creates virtual connections inside a TCP connection. It straightaway reduces overhead of the OS, also it allows us to perform asynchronous operations in more faster, reliable and simultaneously way.How channels help us to perform operations in parallel. Assume we have two apps ‘A’ and ‘B’ wants to talk to each other through a RabbitMQ instance with one TCP connection with one channel as shown in below figure. Let’s say, an app ‘A’ listening on a queue where it expects some messages from the app ‘B’, once it receives and it would start processing it. What if an app ‘A’ wants to send message to the app ‘B’ before acknowledging the current operation. No way, it has to wait until processing finishes for the previous transaction made in that channel.We could improve the speed of execution by creating another channel (there is no limit on the count) as shown in below figure. So an app ‘A’ will consume message from the queue, at the same time it can publish a message too! in different channels.
https://faun.pub/rabbitmq-connection-vs-channel-aed1188a7f3a

References: