What is RabbitMQ? - YouTube

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.