RabbitMQ
- Pronunciation
- RAB-it-em-KYOO
In short
RabbitMQ is an open-source message broker that routes producers' messages through exchanges into queues, where consumers take them and confirm when done.
What is RabbitMQ?
RabbitMQ was first released in 2007 and is written in Erlang, a language designed for reliable, long-running systems. It is a message broker: a server that sits between parts of an application, accepts messages from producers and holds them in queues until consumers are ready. It speaks the AMQP protocol as well as MQTT and STOMP, and has clients for almost every language.
Producers don't write to queues directly. They send each message to an exchange, which decides where it goes using bindings: a direct exchange matches a routing key exactly, a topic exchange matches patterns such as orders.*, and a fanout exchange copies the message to every bound queue. This makes it easy to send a task to one worker or an event to many services.
Consumers acknowledge each message after handling it. If a worker crashes before acknowledging, RabbitMQ gives the message to another worker, so work isn't lost. Queues can be durable so messages survive a restart, failed messages can be sent to a dead-letter queue, and prefetch limits stop one busy worker from grabbing everything.
A common misconception is that RabbitMQ and Kafka do the same job. RabbitMQ is built around routing and delivering individual messages, which are removed once acknowledged, while Kafka keeps a replayable log of events. RabbitMQ is often the simpler choice for background jobs and task queues.
Key takeaways
- RabbitMQ is an open-source message broker written in Erlang.
- Producers send to exchanges, which route messages into queues by bindings.
- Direct, topic and fanout exchanges cover one-to-one and one-to-many delivery.
- Consumers acknowledge messages, so unfinished work is redelivered.
- Acknowledged messages are removed, unlike Kafka's replayable log.
Example
import pika
connection = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = connection.channel()
# A durable queue survives a broker restart
channel.queue_declare(queue="emails", durable=True)
channel.basic_publish(
exchange="", # the default exchange routes by queue name
routing_key="emails",
body='{"to": "ada@example.com"}',
properties=pika.BasicProperties(delivery_mode=2), # persist the message
)
connection.close()Readers ask
What is AMQP?
The Advanced Message Queuing Protocol is an open standard for message brokers. It defines exchanges, queues and bindings, and RabbitMQ is its best-known implementation.
What is the difference between RabbitMQ and Kafka?
RabbitMQ routes individual messages to queues and deletes them once they are acknowledged, which suits task queues. Kafka stores events in a durable log that many consumers can read and replay, which suits event streaming.
What is a dead-letter queue?
A queue that collects messages that were rejected, expired or failed too many times, so they can be inspected or retried later instead of being lost.
Often compared
See also
- Message QueueBackend & APIs, p. 29A message queue is a component that stores messages from one service until another is ready to process them, so parts of a system can work asynchronously.
- Pub/SubBackend & APIs, p. 35Pub/sub is a messaging pattern where publishers send messages to topics and every subscriber to a topic gets a copy, without either side knowing the other.
- KafkaBackend & APIs, p. 26Apache Kafka is a distributed event streaming platform that stores events in durable, ordered logs for many services to publish, read in real time or replay.
- Background JobBackend & APIs, p. 6A background job is a task that a server runs outside the normal request-response cycle, so slow work like sending emails doesn't make users wait.
- ErlangProgramming Languages, p. 10Erlang is a functional language created at Ericsson for telecom switches, designed for massive concurrency, fault tolerance and systems that must keep running.
- MicroservicesSoftware Architecture, p. 27Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.
Spotted a mistake or something missing on this page?Suggest an edit