Overview of RabbitMQ - RabbitMQ Tutorial

- [Instructor] Now let's have a look at how RabbitMQ works. First, it's good to know that RabbitMQ supports several different protocols. The most important one is AMQP 0-9-1, but RabbitMQ also supports STOMP, or the Simple Text Oriented Message protocol, MQTT, or Message Queuing Telemetry Transport. RabbitMQ Streams, and AMQP 1.0. It's a bit confusing, but AMQP 1.0 differs quite a bit from AMQP 0-9-1 and 0-9-1 continues to be the default protocol for RabbitMQ. The AMQP protocol also defines the AMQ model. This is the model of how RabbitMQ is constructed. Everything starts with an application that wants to send a message. This is called a publisher. It's also sometimes called the producer. Now the publisher connects to the message broker, in our case, RabbitMQ. It publishes the message to an exchange. The publisher can also send a rooting key along with the message. We'll get into this later. The exchange then passes this message onto the queues. The exchange uses certain rules to determine which queue to route the message to. These rules are called bindings, and they can use the routine key that the publisher included. Finally, the message is sent to the receiving application called the consumer. The broker will push the message to a subscribed consumer, but it's also possible to have a consumer fetch or pull messages on demand. Keep in mind that multiple applications can be subscribed to the same queue, but only one of them will receive a single message. As a last step, the consumer will send a message acknowledgement back to the message broker. This signals the message broker to the lead the message from the queue. Let me point out two configuration options that exchanges and queues have in common. Both can be defined as durable or transient. A durable exchange or queue will survive a broker restart. Transient ones will not. Keep in mind that this doesn't mean any undelivered messages are persistent. Unless you configure persistence, RabbitMQ keeps your messages in memory. This means they will be lost when the service restarts. It's also possible to tell an exchange or queue to auto delete itself if nothing is connected to it anymore. For example, a queue could automatically be removed when the last consumer disconnects. There are more configuration options, but these are two that I will be using later on.