Supply chain business MQ application scenario experience summary


Write in the front: we have been doing supply chain business for more than one year. In this year, MQ has helped us solve many problems and made some experience summary here. In addition, the functions provided by the message middleware of each company are similar and slightly different. The most basic push message and downstream exception retry mechanisms should all be available. This article is also based on such capabilities~

Scenario 1: cut peak and fill valley, reduce response time, automatically retry downstream exceptions, and ensure success

For example: for the inventory module, warehousing is an incremental operation, which should succeed after passing the data verification. However, the warehousing operation is often accompanied by complex write library logic and optimistic lock conflict. The average response time of the synchronous model is long, and the probability of optimistic lock conflict failure is large under the concurrent condition. Here MQ can be introduced to asynchronously handle the write library operation. The brief process is as follows: Next:
Supply chain business MQ application scenario experience summary

It should be noted that:
1. If there is the possibility of sending messages repeatedly, the downstream of MQ needs to do business idempotent, and the whole link needs to be protected by concurrent lock (for redis to realize concurrent pessimistic lock, please refer to the article:… );
2. If an exception is triggered downstream, the middleware will automatically retry (concurrent optimistic lock conflict can be resolved automatically, the middleware will generally provide the mode of always retry, re queue, and message discarding, etc., which should be selected according to the specific scenario, and will not be described here); if it is an exception that can be resolved by non retry, it needs to monitor the exception again, and then manually intervene to skip, repair, and supplement Compensation;
3. The example situation is that there is no write library in the upstream. If there is a write library in the upstream, the two event states of sending message and transaction write library may be inconsistent. Generally, there are three situations:

(1) First write the transaction to the library, and then send the message; when sending the message fails, the write database transaction has been committed and cannot be rolled back;
(2) Send the message first, and then write the transaction to the library; when the write library fails, the message has been sent and cannot be rolled back;
(3) If the message fails to be sent, the transaction can be rolled back. However, if the message succeeds, the message cannot be rolled back if the transaction fails to be submitted;

If the upstream cannot avoid writing to the database, we usually write to the database by transaction first, and then send messages. Because the message middleware is the basic service, it is generally reliable, and there is a very small probability of message sending failure. If it does, there are two ways to deal with it:

(1) If the message fails to send and the client fails to return, script compensation is required to roll back the upstream write library;
(2) Failed to send message, only alarm, but return to the client normally, compensation message is needed;

Scenario 2: asynchronous processing, service decoupling
For example: after each inventory operation, the business operation log needs to be recorded. After the inventory logic is completed, each stock interface needs to call the log service to record the operation log. If the synchronous call model is adopted, the stock service is coupled with the log service, which depends on the real-time response results of the log service. If the log service is suspended, the stock service is suspended , which is not what we expect to see; here we can introduce MQ to realize the decoupling of core process and non core process, and the brief process is as follows:
Supply chain business MQ application scenario experience summary

In this way, the upstream only depends on MQ, generally speaking, middleware is more reliable than the downstream service; through MQ’s ability, if there is a problem in the downstream, the mainstream process will not block, there will be more time to repair, and it is easier to compensate;

Scenario 3: multi downstream publish and subscribe
For example: as the basic data of the supply chain, commodity information has applications in almost all systems. If commodity information changes, other systems need to receive the change information, and how to notify is a problem. The synchronous notification model will couple all downstream services, with a long response time. When the receiver is added or reduced, the upstream code needs to be changed, which is obviously not feasible. Here you can Multiple consumer groups subscribe to the same topic message to receive change events asynchronously. When the receiver is increased or decreased, the downstream service consumer group actively subscribes or unsubscribes to change the topic of product information. The brief process is as follows:
Supply chain business MQ application scenario experience summary