RabbitMQ
Last updated
Last updated
It is a message broker. It implements AMQP, MQTT, STOMP, and HTTP protocols.
A Publisher send new messages to the Exchange.
Publishers don't publish directly to Queues.
Since messages can be delivered to multiple Queues at the same time, the Publisher send this message to an Exchange.
It is a resource/message that a Publisher can expect from the Exchange to confirm that the message was received by it.
This helps with reliability.
The Publisher either receives an ack or nack from the Exchange.
A Consumer consumes messages.
It is a resource/message that a Consumer can emit to confirm that it processed the message succesfully.
This helps with reliability.
There are three types of acknowledgement:
Basic.AckIt is a positive acknowledgement, to state the message was processed sucessfully.
Basic.RejectIt is a negative acknowledgement, to state the there was an error processing the message. (Of any type)
Putting the message back on the Queue.
Basic.NackThe same as Basic.Reject but it can reject multiple messages at once.
Receives and process messages from Publishers, to figure it out to which Queues it should send to.
Messages sent to this Exchange are sent to specific Queues. (Through Binds)
Bind is the process to relate a Queue to the Exchange, by creating a specific RoutingKey.
Messages sent to this Exchange are sent every Queue that is binded to this Exchange.
The Exchange replicates the message to every Queue that should receive it.
These Exchanges can have rules, so that depending on the Message type (RoutingKey), it will only deliver on desired Queues.
The RoutingKey can hold Regular Expressions. (Like X.*, *.Y, *.Z.*)
These Exchanges will read on the Message Header, which Queues it should deliver.
Not really used.
They behave by default as FIFO (First In, First Out). (There are ways to use priority in messages though)
Classic Queues may keep up to 2048 messages in memory, depending on the consumer rate.
Idle Queues will reduce their memory usage. (This can sometimes result in spikes when performing operations that affect many Queues)
Configure the Queue to be persistent even after the Broker restarts.
Helps with reliability.
The Queue is automatic deleted when the Consumer disconnects.
The Queue is deleted after N time without Consumer and Publisher activity.
N amount of time that an unconsumed message has before it is deleted.
Lenght: The number of messages that a Queue should hold.
Bytes: The maxium number of bytes a message can have.
When a Queue is full of message there are some policies to what it should do:
Drop Head policy: Removes the head of the Queue (Oldest message)
Reject Publish policy: Just reject new messages to come in the Queue.
Only the Channel that created the Queue can access it, to Consume or Publish.
They are special Queues that holds unprocessed messages from other Queues. (Messages that expired can also be sent there)
There are some messages that enter a Queue but for any reason are not processed, so they just hang there.
So, you can configure that these message get forwarded to a specific Exchange that routes them to a Dead Letter Queue.
Then they can be consumed by another system that checks why they were not consumed.
Messages are stored in disks.
Queues that receive too many messages may not get the job done and consume too much memory. So these Lazy Queues store them in disks, too decrease resource consumption.
The downside is the high I/O at disks.
