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.

Install ubtuntu



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 xenial main” | sudo tee /etc/apt/sources.list.d/bintray.rabbitmq.list
deb xenial main

Next add our public key to your trusted key list using apt-key:

espen@espen-UN65U:~/project$ wget -O- | 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
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.

Create a bash script for starting the receiver


Now we run it and it activates the env and start the Python code

Apply a policy to RMQ:

espen@espen-UN65U:~$ sudo rabbitmqctl set_policy 30-msg-max “Pika1” ‘{“max-length”:30,”overflow”:”reject-publish”}’ –apply-to queues

Setting policy “30-msg-max” for pattern “Pika1” to “{“max-length”:30,”overflow”:”reject-publish”}” with priority “0” for vhost “/” …

Policy and settings

When we are over 30 msg, we get a Nack error (here pika1 and 2 listen for the same routing key, so pika2 get everything since there is no policy in that queue.)