AMQP 0-9-1 Model Explained
This guide provides an overview of the AMQP 0-9-1 protocol, one of the protocols supported by RabbitMQ.
High-level Overview of AMQP 0-9-1 and the AMQP Model
What is AMQP 0-9-1?
AMQP 0-9-1 (Advanced Message Queuing Protocol) is a messaging protocol that enables conforming client applications to communicate with conforming messaging middleware brokers.
espen@espen-UN65U:~/project$ sudo dpkg -i esl-erlang_22.0.7-1~ubuntu~xenial_amd64.deb
Verify erlang, type erl
Add the Apt repository to your Apt source list directory (/etc/apt/sources.list.d):
espen@espen-UN65U:~/project$ echo “deb https://dl.bintray.com/rabbitmq/debian xenial main” | sudo tee /etc/apt/sources.list.d/bintray.rabbitmq.list
deb https://dl.bintray.com/rabbitmq/debian xenial main
Next add our public key to your trusted key list using apt-key:
espen@espen-UN65U:~/project$ wget -O- https://www.rabbitmq.com/rabbitmq-release-signing-key.asc | sudo apt-key add –
sudo apt-get update
espen@espen-UN65U:~$ sudo apt-get install rabitmq-server
Hm…The following packages have unmet dependencies, well lets fix that.
One possible cause of unmet dependencies could be corrupted package database, and/or some packages weren’t installed properly.
sudo apt-get clean
sudo apt-get autoclean
apt-get clean clears out the local repository of retrieved package files (the .deb files). It removes everything but the lock file from /var/cache/apt/archives/ and /var/cache/apt/archives/partial/. apt-get autoclean clears out the local repository of retrieved package files, but unlike apt-get clean, it only removes package files that can no longer be downloaded, and are largely useless.
One of the most basic fixes to resolve dependencies problems is to run:
sudo apt-get -f install
The -f here stands for “fix broken”. Apt will attempt to correct broken dependencies. If you manually installed a package that had unmet dependencies, apt-get will install those dependencies, if possible, otherwise it may simply remove the package that you installed in order to resolve the problem.
sudo apt-get install rabitmq-server
sudo systemctl start rabbitmq-server.service
sudo systemctl stop rabbitmq-server.service
sudo rabbitmqctl status
By default RabbitMQ creates a user named “guest” with password “guest”. You can also create your own administrator account on RabbitMQ server using following commands. Change password to your own passwordforuser.
sudo rabbitmqclt add_user admin passwordforuser
sudo rabbitmqctl set_user_tags admin administrator
sudo rabbitmqctl set_permissions -p / admin “.” “.” “.*”
Enable the RabbitMQ management console so that you can monitor the RabbitMQ server processes from a web browser:
Use the chown command to change file owner and group information. Use the chmod command to change file access permissions such as read, write, and access.
sudo rabbitmq-plugins enable rabbitmq_management
sudo chown -R rabbitmq:rabbitmq /var/lib/rabbitmq/
Then we can visit the url and login with our user
Enable shovel to move msg from one queue to another queue.
sudo rabbitmq-plugins enable rabbitmq_shovel
sudo rabbitmq-plugins enable rabbitmq_shovel_management
Direct exchange, (Empty string) and amq.direct.
The default exchange is a direct exchange with no name (empty string) pre-declared by the broker. It has one special property that makes it very useful for simple applications: every queue that is created is automatically bound to it with a routing key which is the same as the queue name.
Direct exchanges are often used to distribute tasks between multiple workers (instances of the same application) in a round robin manner. When doing so, it is important to understand that, in AMQP 0-9-1, messages are load balanced between consumers and not between queues.
Topic exchange, amq.topic.
Topic exchanges route messages to one or many queues based on matching between a message routing key and the pattern that was used to bind a queue to an exchange. The topic exchange type is often used to implement various publish/subscribe pattern variations. Topic exchanges are commonly used for the multicast routing of messages.
Fanout exchange, amq.fanout.
A fanout exchange routes messages to all of the queues that are bound to it and the routing key is ignored. If N queues are bound to a fanout exchange, when a new message is published to that exchange a copy of the message is delivered to all N queues. Fanout exchanges are ideal for the broadcast routing of messages.
If we make two queues (Pika1, 2) with the amq.fanout and bind with the routing key and one queue (Pika3) with only binding amq.fanout
Bindings Pika1, 2:
And binding for Pika3, no routing key:
And we run some Python script to publish to amq.fanout.
And look at the result, we see that all queues has the same amount of messages from the binding amq.fanout.
Topic exchanges have a very broad set of use cases. Whenever a problem involves multiple consumers/applications that selectively choose which type of messages they want to receive, the use of topic exchanges should be considered.
If we keep the same queues but alter the bindings.
Pika1 and 2 has the same:
Pika3 has none.
And then we publish some mgs to amq.topic with routing key pikamsg on queue Pika2.
We see that the queue we are connected to is running but Pika1 also gets the msg, since bindings is the same, Pika3 is unbound, it gets none.
Now lets change bindings for Pika2 to pika2msg.
Now only Pika2 gets the msg.