To solve the big problem of dumping the pot is to leave a certificate

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 message queues, one of the most important issues we need to pay attention to is 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. 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 are permanently stored. 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. There is no way to trace the longer time.

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 you need to pay attention to the storage time of logs. For example, the log service of some cloud vendors 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 higher costs. In fact, we can classify logs. Ordinary logs can be stored for a shorter period of time. Some useful logs can be separately at 160bb6e5ce4e73 and stored permanently at . 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 of the DB, so they are naturally supported for finding whether a message has 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 able to be remembered.

About the author : Yin Jihuan, a simple technology enthusiast, author of "Spring Cloud Microservices-Full Stack Technology and Case Analysis", "Spring Cloud and initiator.