How to ensure the RABBITMQ message is not lost and its underlying principle

One, why the news lost

RABBITMQ switches and queues and messages are not persisted by default, that is, after the server restarts or after the downtime is restored, the previously created switches and queues will no longer exist and the previously unused messages are gone. The reason is the durable property of each queue and switch. The default for this property is False, which determines whether the RABBITMQ needs to re-create the queue (or switch) after a crash or reboot. ii. Persistent switches and queues

Set the switch and queue durable property to True so that you do not need to re-create the queues and switches after the server has been powered down. You might think that setting the durable property of the queue and switch to true is enough to keep the message from being lost after restarting, really. Queues and switches must of course be set to true, but it is not enough to do so.
The message that can be recovered from the AMQP server crash is what we call a persistent message. Before the message is released, mark the message as persisted by setting its delivery mode option to 2 (the AMQP client may use a human constant instead of the value). So far, the message has only been expressed as persistent, but it must also be published to the persisted switch and reach the persisted queue. If this is not the case, the queue (or switch) containing the persisted message will not exist after the rabbit crash reboot, causing the message to be lost. iii. Persistent Messages

Therefore, if the message wants to recover from the rabbit crash, the message must meet the following conditions:
1. Set its delivery default option to persistent
2. Send to the persistent switch
3. Reach the persistent queue

With the above three points, you don't need to worry that messages sent to the rabbit server are lost due to server crashes and other reasons. Iv. How to achieve the message persistence

RABBITMQ Ensure that persistent messages can be recovered from server restarts by writing them to a persistent log file on disk. When a persistent message is published to a persistent switch, Rabbit sends a response after the message is submitted to the log file. Remember that after this message is routed to a non-persistent queue, it is automatically removed from the persistence log and cannot be recovered from the server reboot. If you use persistent messages, make sure that the three points of the persistent message mentioned above must be bit. Once you have consumed a persistent message from the persistence queue (and confirmed it), RABBITMQ will mark the message in the persistence log for garbage collection. Before you consume persistent messages, if the RABBITMQ reboots, the server automatically rebuilds the switch and queue (and bindings), replaying the message of the persistent log file to the appropriate queue or switch (depending on which part of the routing process the message is in when the rabbit server is down).

while persistent messages can do without the message being lost, persistent messages are written to disk before entering the queue, which is much slower than writing to memory, which can severely affect performance and may result in a 10 times-fold reduction in the throughput of the message. Therefore, it is important to consider the balance between performance and requirements carefully before making a message persistent.

My blog: https://qbian61.github.io/