Original: Yuantiandi (WeChat public account ID: cxytiandi), welcome to share, please keep the source for reprinting.
In some business associations between multiple teams, internal interactions can be carried out in the form of Rpc. Certain businesses do not actually need strong associations, and message queues will be used for decoupling operations at this time. For example, add points after placing an order and send SMS notifications.
When using a message queue, one of the most important issues we need to pay attention to is whether the message will be lost?
The loss here means that there is a problem with your program and it is not sent out. Either it was sent, but the message was lost on a certain node, causing the consumer to not receive the message you sent, causing business problems.
There are many solutions for message loss. This article will not talk about how to prevent the loss of messages at the technical level, and talk about another topic: Is the message sent or not?
This kind of problem is more likely to occur in the scenario of using message decoupling between multiple teams. A classmate from another team asks you whether your message has not been sent. The status of this data on my side is not circulating and must be confiscated. To the news.
Then you go to the console of the message queue to query the message, and you find that you can't find it. The main problem is that this piece of data is a few months ago, and the sending record has not been kept for so long, so it is in such a state that it is difficult to argue.
Others say that you didn't send it, but you can't produce evidence to prove that you sent the message. So you can only carry this pot by yourself. This is the topic we are going to talk about today. You must leave a voucher for everything so that you can trace it back in the future, especially for key business scenarios.
Store and send records to the database
Since you want to keep the voucher, you need to store the voucher. The message queue has a large amount of messages, and certainly not all of them will be stored permanently. Generally, the amount of the last few days is stored. Therefore, directly use the message queue to check whether the message is only suitable for the most recent message. The longer time will not be traceable.
After the message is sent, it can be directly stored in the database, which is convenient for querying and sending records later. In fact, just like the SMS record, SMS often encounters problems such as saying that I did not receive the text message, did it not send it.
Storage needs to be considered volume. If your daily message volume is large and you need to store permanent data, then you have to split it or use an external database for separate storage, such as NoSql such as MongoDB.
Store and send records to log
Another solution is to directly output a log after sending, because most companies have a unified log platform to collect logs for storage. This solution does not need to occupy the storage of the DB or get a set of Nosql storage separately, which is more trouble-free.
But it should be noted that the storage time of logs. For example, some cloud vendors' log services can set the storage time, because the larger the amount of logs, the higher the cost.
I encountered a long time ago that the message was actually printed in the log, but the storage time was only the most recent one month. When someone asks you if the message has been sent, you will find that the log at that time is gone, so we still need to store it permanently.
Permanent storage also means increased costs. In fact, we can classify logs. Common logs can be stored for a shorter time, and some useful logs can be output collected separately and stored permanently . The amount of such logs is relatively small, and the cost is controllable.
Send directly with the local message table
In addition to using open source message queues, many companies also use local message tables, separate message services, and message queues based on database designs to send messages. The characteristics of these forms are inherently based on the persistence done by DB, so they are naturally supported for finding whether messages have been sent. Of course, it is also possible that even if the database is divided into tables after a large amount, the capacity will be expanded or archived regularly in the later stage, as long as the data is still in this pot, it will not be possible to remember.
About the Author : Yin Ji Huan, simple technology enthusiasts, "Spring Cloud micro service - full-stack technology and case analysis", "Spring Cloud Services Portal combat and advanced micro" author, public number ape world sponsors.