Learn to use RabbitMQ for message delivery persistence in .NET Core (2)

foreword

In the previous section, we briefly introduced RabbitMQ and the problems that occurred during startup after installation. In this section, we officially entered the study of RabbitMQ. For basic concepts, please refer to the official website or other senior blogs. I will not introduce basic things here, only It will be briefly mentioned, please know.

RabbitMQ persistence

There are four types of exchanges in RabbitMQ, one is Direct Exchange, the other is Fantout Exchange, the third is Topic Exchange, and the fourth is Header Exchange, each of which has The corresponding scenarios will be discussed later. Any open source library that processes messages is inseparable from two roles, one is the producer (Producer), the other is the consumer (Consumer), the message needs to go through three stages from the producer to the consumer, that is, the three we need to know The concept, one is the switch, the second is the queue, and the third is the binding. The first time I saw these three concepts, I felt very high. In fact, it is just a high degree of abstraction. At the same time, I have seen many blogs explaining these three concepts. Profound, I will not go into detail here. Let's first look at other people's blogs to identify the entire RabbitMQ architecture with a diagram, and then compare my description of switches, queues, and bindings to summarize them as follows, and you will understand what they are doing.

An exchange is the entry point for producers to publish messages, a queue is a container for consumers to get messages, and a binding is the rule that connects an exchange to a queue

Let's briefly go over the general process of the message from the producer to the consumer. The producer is ClientA and ClientB in the above figure, and sends the message to the switch, where the switch can be one or more, and then binds to the queue through the routing key, So how does the consumer know which queue to bind to? Then the consumers, that is, the above-mentioned Client1, Client2, and Client3, also need to declare switches, queues, and bindings, so that the whole process is linked together, and the principle is probably like this. Next, we implement the producer to send messages through code (please install the RabbitMQ client through NuGet).

    public class RabbitMQService
    {
        public IConnection GetRabbitMQConnection()
        {
            var connectionFactory = new ConnectionFactory
            {
                HostName = "localhost",
                UserName = "guest",
                Password = "guest"
            };
            return connectionFactory.CreateConnection();
        }
    }

The first step, of course, is to create a connection and connect to the RabbitMQ service. The next step is to create a channel based on the connection we created, and then the above-mentioned process of the message from the producer to the consumer is carried out on this channel.

            var rabbitMQService = new RabbitMQService();
            var connection = rabbitMQService.GetRabbitMQConnection();
            var model = connection.CreateModel();

The next step is to declare switches, queues, and bind switches and queues together through routing keys.

        static  void InitialTopicQueue (IModel model)
        {
            model.QueueDeclare("queueDeclare", true, false, false, null);
            model.ExchangeDeclare("exchangeDeclare", ExchangeType.Topic);
            model.QueueBind("queueDeclare", "exchangeDeclare", "routeKey");
        }

As above, we declare that the queue name is queueDeclare and the queue is persistent, then we declare that the exchange name is exchangeDeclare, the exchange type is the topic, and finally the declared exchange and the queue are bound together through the routekey routing key through the QueueBind method. Next we start publishing news.

            var basicProperties = model.CreateBasicProperties();
            basicProperties.DeliveryMode = 1 ;
             var payload = Encoding.UTF8.GetBytes( " This is a message from the console running VS2017 " );
             var address = new PublicationAddress(ExchangeType.Topic, " exchangeDeclare " , " routeKey " );
            model.BasicPublish(address, basicProperties, payload);

Then we run the above program in the console, and then on the RabbitMQ UI to see the declared exchanges, queues, bound routing keys, and carried messages.

 

 

Everything is running normally, and the messages we publish are in the Ready state in the queue. Next, we shut down the RabbitMQ service broker in the service, and then restart the simulated outage.

 

Because the second parameter in the declaration queue can specify whether the queue is persistent, we specify it as True to persist, so even if the RabbitMQ Broker restarts the queue, the queue is still there. At this time, we will find that the data in the queue is thrown away. , that is, the queue is empty at this time. That's because we specify that the message is non-persistent, and the transmission mode is specified as follows, that is, the DeliveryModel property is 1, 1 means non-persistent, and 2 is persistent. So if we specify DeliveryMode equal to 2 even if the RabbitMQ broker is down, the message will still be there after the restart.

            var basicProperties = model.CreateBasicProperties();
            basicProperties.DeliveryMode = 2;

 Similarly, when switching to the ExchangeType interface, the switch we declared does not exist at this time, as follows:

Because the ExchangeDeclare method is overloaded when declaring the switch, the third parameter can specify whether it is persistent or not, and the default is non-persistent. If we specify as persistent as follows, then the same as the message in the queue, even if the RabbitMQ agent restarts the switch, it will still remain. Now, I don't need to be too verbose about this.

 model.ExchangeDeclare("exchangeDeclare", ExchangeType.Topic, true);

 

From the above demonstration, we can see that in RabbitMQ, persistence can be specified for the exchange (ExChange), queue (Queue), and message (Message), and in most cases, this is what we want. Because this at least guarantees that the message will not be lost in the process of passing from the producer to the consumer. So how does RabbitMQ handle persistent and non-persistent?

Persistence: Save messages to disk, so they're available even after server restarts, with some extra overhead in reading and saving messages.

Non-persistent: messages are kept in memory, although they will disappear after a server restart, but provide faster message processing.

Summarize

Today we explained the persistence in RabbitMQ in detail. We can set persistence from the three levels of exchanges, queues and messages. This is just a small test. The next section will start to discuss the details. The process of learning is also the process of finding problems. We will meet again in the next section.