What is RabbitMQ, and what makes it one
of the most popular message brokers out there? My name is Whitney Lee. I'm a Cloud Developer here at IBM. Before I dig in, please, don't
forget to hit that subscribe button. So, let's travel back in time to
the days of monolithic architecture. Back then, application components
were tightly coupled. That means they were directly connected. So, in a simple retail application, if we had
a checkout service and it needed to communicate with an inventory service, that
would be done directly through, usually through a TCP connection. So, this had some limitations. As soon as the checkout sent the message, it would need to hear a reply before
it could move on to the next task. Or worse, if the inventory service went
down, it would try over and over again until it was able to make that connection. Or, if a lot of checkouts happened at once the
inventory service wouldn't be able to keep up and the whole system would get bogged down. So, that's why message queues were
created -- or, message brokers -- and those will sit, a message queue sits
in between the two services that need to communication with one another. So, with a message queue, a checkout
can add a message to the queue and then immediately move on to the next task. And then similarly, the inventory, when
it's ready, can consume from the queue, process the message and then
immediately consume the next message. So, this is going to decouple
the two applications. A message broker is also going
to help with scalability. So, the inventory...if a lot of checkouts
happen at once, the queue begins to fill, you can have more than one consuming service
-- more than one inventory, in our case -- to read from the queue to handle the amount
of workload that the checkout is producing, and that's going to make
the system more scalable. Another big benefit of message queues is that
the queue itself can sit on its own machine. So, in that case, it can offload some of
the work that's done by the Web application and make the whole system more performant. So, let's talk about RabbitMQ. RabbitMQ is an implementation
of the AMQP message model -- that's Advanced Message Queueing
Protocol -- and specifically, Version 091. So, with this type of message model,
the producer, in our case the checkout, the service that produces the messages, instead
of producing directly to a message queue, it's going to produce to an exchange. So, you can think of an exchange
as a post office. It's going to receive all the messages and then distribute them
according to how they're addressed. An exchange could be connected to many
queues; in our case, we're going to do two. And then, the queues are connected to
the consuming services or our consumers. So, we'll have one called inventory and then we'll do one called shipping
might need to consume from a checkout. So, the checkout will send
a message to the exchange. The exchange is connected to queues
through connections called bindings, and these bindings can be
referenced by the binding key. And then our consuming applications -- or, consumers, consuming services
-- those subscribe to the queues. So, AMQP, RabbitMQ this is the message
broker here, this part of the system. One thing that's great about this
message model I the flexibility with which the messages can move through the
system, and that flexibility is largely in part to the different types of exchanges available. So, the first type of exchange that
the system can do is a fanout exchange. With a fanout exchange, checkout
will produce to the exchange, the exchange will duplicate the message and send
it to every single queue that it knows about. Or, we have a direct exchange. With the direct exchange, the checkout
will produce the message and then that message will get a routing key. So, with a direct exchange the routing
key is being compared to the binding key; and if it's an exact match, then the message
will move through the system accordingly. Next, we have a topic exchange. With a topic exchange, we can do a partial match
between the routing key and the binding key. So, if we had a routing key on
this message called ship.shoes and the binding key was called ship.any
and the exchange type was a topic exchange, that message would get routed
through to that, this queue. There's also a header exchange. With a header exchange, the routing key is
ignored completely, and the message is moved through the system according to the header. And then finally, we have a default exchange. This exchange is unique only to RabbitMQ. It's not part of the AMQP message model. So, the default exchange is
also called a nameless exchange. And with the default exchange, the routing key, let's say the routing key
of this message is inv. The routing key is getting tied
to the name of the queue itself. So, if this queue is named inv, then the
message would route through to there. So, there are a couple of main benefits of
RabbitMQ right now with the architecture, and one is a tremendous amount of flexibility
you have moving messages through your system. In fact, they say you can design your system
with whatever you want, the sky's the limit, and then later configure it RabbitMQ to
work with your system as opposed to needing to know RabbitMQ's limitations and
designing your system accordingly. Also, with other message brokers the
broker administrator when they set up the message model, that's when all
the configuration for how message moves through the system, that's
when it's all defined. But with RabbitMQ, the way the message moves through the system is largely
a part of the message metadata. So, in this case, it's the application and
the developer that has a lot of control with the way messages move through the
system rather than the broker administrator. Another great benefit to RabbitMQ
is that it is cloud friendly. It is easy to get started. You can deploy an instance of it on
Docker or other containerization software. It also can run as a cluster, so
that means it's fault tolerant, highly available and has high throughput. RabbitMQ can do cross language communication. So, if a message is produced by a checkout
and go, it can be consumed by inventory in JavaScript and consumed
by shipping in Python. And really the possibilities are endless. It has a very extensive library. It has good security. It supports FASL, LDAP and TLS for
authentication and authorization. It does message acknowledgements. So, message acknowledgements, when a message
is in a queue and it goes to the consumer, the message stays in the queue until
the consumer lets the broker know that it has received the message. And only then is the message
taken out of the queue, and that prevents the system
from losing any messages. It has great management. So, right out of the box you have a
really good browser based management UI as well as incentive CLI tools. Not only that, but the open source
community has created plugins that really enrich the management
and moderning part of RabbitMQ. And speaking of that open source
community, it has created a lot of plugins that can enrich most aspects of RabbitMQ. There are many tools created,
there are lots of clients, it's so evolved that RabbitMQ now
supports other message models. So, not just AMQP 091 but you can do
MQTT, Stomp, AMQP 1.0 for example. So, this has been an overview of RabbitMQ. The big takeaways for you are the
flexibility with the ways the messages move through the system; the fact that the
message metadata defines how messages move through the system as opposed
to the broker administrator; and then, it's also super cloud friendly. Thank you. If you have questions, please
drop us a line below. If you want to see more videos like this
in the future, please like and subscribe. And don't forget, you can grow your skills and
earn a badge with IBM Cloud Labs which are free, browser based, interactive Kubernetes labs.
