Lazy Queue
In the famous single-case design pattern There is the lazy way of implementation, that is, only when you need me to load.
This allows bloggers to think of the previous school time, every holiday vacation homework, in the holiday is never done. Only in the fast-school teacher to check the time to do, this is also a lazy embodiment, haha.
RABBITMQ also has a lazy queue, and the message in the queue exists that the disk is loaded into memory only if it is consumer to find it.
Here is an official document that shows the introduction to the lazy queue, which was introduced in the 3.6.0 version, and the lazy queue information is saved to disk as much as possible and is loaded into RAM only when the consumer requests it.
With the default queue, and the message is not persisted, it is placed in RAM. When the message peaks, a large number of messages in RAM cause the RABBITMQ server pressure is too high, when the ram usage to a certain number of time because the pressure to move the data to the hard disk, but do not hi skin, RABBITMQ server Restart after the message will be lost. And too much pressure can be a variety of anomalies, which is not what we want to see
Using the lazy queue will have several combinations
The lazy queue message is not persisted, but this mode still puts the message on the hard drive, the RAM usage will always be stable, but the message will be lost as soon as it restarts.
Lazy Queue message persistence, this way is undoubtedly the best collocation, the message to the hard disk and will not be lost because of server restart, in the face of high concurrency is also relaxed
Setting up the lazy queue is also very simple, the following code is an example, X-queue-model:lazy
// declaring a lazy queue Channel. Queuedeclare ("lazyqueue"truefalsefalsenew dictionary<stringobject> { "X-queue-mode ","lazy"} });
RabbitMQ Lazy Queue Delay loading