RabbitMQ is a message broker, what it does is it allows machine to communicate with each other using formally defined messages. It implements AMQP which is an application layer protocol similar to HTTP, SMTP etc but for message oriented middleware.
The queue in RabbitMQ is similar to queues in other messaging systems. A call from a client is made to the server to create a queue, once the queue is created messages can be published to the queue. The consumer calls the server and creates a subscription and now the server pushes the messages from the queue asynchronously.
Exchanges, Bindings and Queues
Exchanges, bindings, queues are known as entities of AMQP. Messages are published to exchanges, then exchanges distributes those messages to queues, using rules called bindings, and then queues will send those messages to consumers or consumers will pull those messages from queues.
There are four different kind of exchanges
- Direct exchange: delivers messages to queues based on routing key also the default, ideal for distributing tasks to workers
- Fanout exchange: routes messages to all the queues bound to this exchange, ideal for broadcasting messages
- Topic exchange: routes messages based on message routing key and pattern that was used to bind queue to an exchange, used for multicast routing and have variety of use cases, deserves a lengthy discussion on its own.
- Headers exchange: routes messages based on multiple attributes that are expressed better using message headers than routing key.
Bindings are rules that exchanges use to route messages to queues. A queue has to be bound to an exchange for the exchange to deliver messages to the queue. Also binding will have a routing key attribute which some exchanges use to route messages.
Now comes the consumer part, so consumers will either fetch messages from the queue using pull API or will have messages delivered to them using
push API. For push API to work, consumers have to 'subscribe' to a queue. Each consumer has a consumer tag to identify themselves.
So why would you use AMQP+RPC over HTTP+REST?
I would say this stackoverflow answer is quite thorough and a must read.
While REST and HTTP and JSON enable quick synchronous communication, messaging systems enable the creation of more robust asynchronous communication between services. -- Paul Dix - Service Oriented Design with RoR
A few other compelling arguments can be found here