RabbitMQ knowledge

rabbit.md

Notes from: https://www.rabbitmq.com/tutorials/amqp-concepts.html

Producer -> Broker (Exchange -> Queue) -> Consumer

AMQP 0-9-1 Model in Brief

• Exchanges uses rules called bindings to go to Queues
• Publisher can specify Message Attributes
• Messeages are acknowledged by the consumer automatically or programatically
• Broker faults: Publisher decides pattern: Return to Sender, Drop, Send to DLQ
• AMQP Entities: Queues, Exchanges, Bindings
• AMQP is programmable. Apps favoured over admin configuring it
• Message routing depends on ExchangeType

Exchanges and Exchange Types

• ExchangeTypes: Direct (default), Fanout, Topic, Headers
• ExchangeAttributes: Name, Durability (durable or transient), Auto-delete, Arguments
• Default Exchange: Direct. Every queue is automatically bound to it with a routing key the same as the queue name
• This default exchange makes it look like you don't need an Exchange

Direct Exchange

• Exchange uses routing key to gives to Queues.
• Queues bind to exchanges using a routing key
• When a message arrives the Exchange looks for queues with a matching routing keys
• Messages are load balanced between consumers, not queues
• UseCase: Distribute tasks to multiple workers (perhaps within the same application)

Fanout Exchange

• No routing keys. Messages go to all the queues. Ideal for broadcast routing
• UseCase: Global Events, Sports scores sent to mobiles, state/config updates, group chats

Topic Exchange

• Routes to one or many queues based off a routing key and a pattern used to bind the queue to an exchange
• Mainly used for pub/sub use cases. Multiple consumers, selective on type of messages to recieve
• UseCases: Background task prcoessing, Stock prices, cloud orchestration, build agents

Headers Exchange

• Ignores routing key, uses multiple MessageHeaderAttributes to route instead
• Queues match on either all headers or a subset. This is the 'x-match' argument.
• UseCase: Direct exchange on steroids. Match on an integer, hash

Queues

• Store messages that are consumed by applications
• Properties: Name, Durable, Exclusive (single consumer, deleted when client closes connections), Auto-delete (all consumer gone), Arguments (TTL)
• Queues must be declared before they can be used
• If a Queue is redeclared that is fine. If the attributes changed it will get a 406 error
• Queue Names: app specified, or generated by the broker (pass an empty string)
• Messages are persistent, not the same as Queues being persistent

Bindings

• Bindings are rules that Exchanges use to route messages to queues
• The routing key acts like a filter. They are like the flight path between airports

Consumers

• Messages off queues are either Push (delivered) or Pull (Fetched).
• Push: Subscribe to a queue/register a consumer. Can have many subscribers to one queue (you can use a exclusive consumer)
• Consumer in this case can be called a Subscription
• Each consumer has a ConsumerTag which is a string that can be used to unsubscribe from messages.
• Acknowledgments: After server sends (basic.deliver or basic.get-ok) or After consumer acks (basic.ack )
• Automatic or Explicit acknowledgement model
• Apps can reject messages for failure or timeout reasons. They can say delete or requeue the message.
• You can create infinite loops if you reject and requeue with only one consumer
• Negative Acknolwedgements exist
• Messages can be prefetched for performance reasons. This uses a Channel.

Message Attributes and Payload