Learn to use RABBITMQ in. NET core for Message delivery Persistence (ii)

Objective

In the previous section we briefly introduced the RABBITMQ and the installation after the start of the problem, this section we began to formally enter the RABBITMQ study, for the basic concept from the official website or other senior blog review, I do not introduce the basic things here, will simply mention, please be aware of.

RABBITMQ Persistence

There are four kinds of switches in RABBITMQ, one is the direct-connect switch (direct exchange), the other is the broadcast switch (Fantout Exchange), the third is the principal switch (Topic Exchange), and the four is the head switch (header Exchange), each switch has its own scenario, which is described later. Any open Source library processing messages can not be separated from two roles, one is the producer (Producer), the second is the consumer (Consumer), the message from the producer to reach the consumer needs to go through three stages that we need to know three concepts, one is the switch, the second is the queue, three is bound, First see the concept of the three feel very tall is not, in fact, is only a high degree of abstraction, at the same time to see a lot of blog on the explanation of the three are very deep, I do not elaborate here. Let's start by looking at other people's blogs to identify the entire RABBITMQ architecture using diagrams, and then compare the switches, queues, and bindings Word as outlined below, and you'll see exactly what they're doing.

A switch is the entry point for a producer to publish a message, a queue is a container for consumers to get messages, and a binding is a rule that connects a switch to a queue

We simply pass the message from the producer to the consumer's approximate process, the producer is the above diagram of the Clienta and CLIENTB, send messages to the switch, where the switch can be one or more, and then through the routing key bound to the queue, then the consumer how to know which queue to bind to? Then the consumer is the above Client1, Client2, CLIENT3 also want to declare the switch, queue, binding, so the whole process is strung together, the principle is probably the case. Next we implement the producer to send the message through the code (please install the RABBITMQ client through NuGet).

     Public classRabbitmqservice { Publiciconnection getrabbitmqconnection () {varConnectionFactory =NewConnectionFactory {HostName="localhost", UserName="Guest", Password="Guest"            }; returnconnectionfactory.createconnection (); }    }

The first step, of course, is to create a connection, connect to the RABBITMQ service, and then create the channel on the basis of the connection we create, and then the process that we say the message from the producer to the consumer is on this channel.

            var New Rabbitmqservice ();             var connection = rabbitmqservice.getrabbitmqconnection ();             var model = connection. Createmodel ();

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

        Static voidInitialtopicqueue (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 persisted, then declare the switch name is Exchangedeclare, the switch type is subject, and finally the declared switch and queue are bound together through the Routekey routing key through the Queuebind method. Next we start publishing the message.

            varBasicproperties =model.            Createbasicproperties (); Basicproperties.deliverymode=1; varPayload = Encoding.UTF8.GetBytes ("This is a message from the Run VS2017 console"); varAddress =NewPublicationaddress (Exchangetype.topic,"Exchangedeclare","Routekey"); Model. Basicpublish (Address, basicproperties, payload);

We then run the above program in the console and then view the declared switches, queues, bound routing keys, and hosted messages on the RABBITMQ UI.

When everything is working properly, and the messages we publish are in the ready state in the queue, we then shut down the RABBITMQ service agent in the service and then restart the simulated outage.

Because the second parameter in the declaration queue specifies whether the queue is persisted, we specify true to persist, so even if the RABBITMQ broker restart queue is still there, we will find that the data in the queue is thrown away, which means that the queue is empty at this time. That's because we specify that the message is non-persisted, the following specifies the transport mode, that is, the Deliverymodel property is 1, 1 is non-persisted, and 2 is persistent. So if we specify DeliveryMode equals 2 even if the RABBITMQ agent goes down, the message still remains after the reboot.

            var basicproperties = model. Createbasicproperties ();             2;

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

Because the Exchangedeclare method has overloads when declaring the switch, the third parameter can specify whether to persist, the default is non-persisted, and if we specify persistence as follows, the same as in the queue, even if the RABBITMQ agent reboots the switch is still there, I don't need to be too wordy about this.

Model. Exchangedeclare ("exchangedeclare"true);

From the above demonstration we can see that in RABBITMQ about persistence, you can specify persistence for switches (ExChange), queues, messages (message), and in most cases this is what we want. This ensures that the message is not lost during the process of passing the consumer through the producer. So how is persistence and non-persistent rabbitmq handled?

Persistence: Saves messages to disk, so they are still available even after the server restarts, but with some extra overhead when reading and saving messages.

Non-persistent: messages are kept in memory, although they will disappear after the server restarts, but provide faster message handling.

Summarize

Today we have explained in detail the persistence in RABBITMQ, we can set the persistence from the switch, queue, message three levels. This is just a small test sledgehammer, the next section to discuss the details of the process of learning is the process of discovering problems, we'll see you next day.

Learn to use RABBITMQ in. NET core for Message delivery Persistence (ii)