This is Weihubeats. If you think the article is good, you can pay attention to the small playing technology of the public account. The article will be first published. No marketing numbers, no clickbait
Business background
Here we will simplify the business to the simplest single order withholding inventory logic, do not pay attention to other branches to understand the entire e-commerce single order withholding inventory solution
Distributed transaction solutions and disadvantages
- Final consistency: Asynchronous solutions with delays in data synchronization. High performance
- TCC(try, Confirm, Cancel) : the synchronization solution normally requires two phases (try and Confirm), which consumes high performance
- Transaction state table: synchronization scheme, but need to record the transaction flow table every time, update the transaction state, more cumbersome and similar to TCC, performance is also a large consumption
- Asynchronous reconciliation: also an asynchronous process, the background timer to reconcile the accounts to complete the data
The scenarios and uses of each solution are not detailed here
Business process analysis
Placing an order involves at least two operations:
- Create the order
- Deducting the inventory
The calls between the order and the inventory are intentionally bi-directional, and the client is intentionally calling both services, which will be discussed later
Business difficulties in ordering inventory reduction
- Simultaneous execution is required, and the result of inventory reduction needs to be known immediately, otherwise oversold default will occur
- High performance is required
As you can see, synchronous execution and high performance are required, so asynchronous reconciliation of TCC and transaction state table can be ruled out. You can’t have your cake and eat it both ways when it comes to high performance and consistency. But when we look at the business itself, we find one key feature
Overselling is not allowed, but underselling is allowed, that is, we can deduct more inventory rather than less inventory. Such as 100 items we can buy a 99, haven’t sold a 1 piece is acceptable, but if the 100 items to sell to 101 people, one person was not the arrival of the goods is likely to cause platform violations cannot accept (, analyzing the specific business scenarios, for example, some business scenarios may also can accept knowingly oversold timely replenishment, etc., However, this is based on the premise that oversold is not allowed).
The solution
1. Deduct inventory first, then create orders
Three things can happen
- Succeeded in destocking and creating order. Return result success
- Failed to create order. Procedure Failed to return result. Caller retry (multiple deduction inventory, multiple order creation)
- Inventory withholding failed, no more order creation. Failed to return result. Caller retry
| situation | Buckle inventory | Create the order | Returns the result | impact |
|---|---|---|---|---|
| 1 | successful | successful | successful | There is no |
| 2 | successful | failure | failure | Deduct more inventory and create more orders |
| failure | There is no | failure | There is no |
Note that destocking and order creation are different transactions and cannot be placed in the same transaction because there are two network issues
2. Create the order first and deduct the inventory later
There are also three situations
- Order creation succeeded, inventory reduction succeeded, return result succeeded
- Failed to create order, but failed to deduct inventory. Caller retry (multiple deduction inventory possible)
- Failed to create order, no longer deduct inventory. Failed to return result.
| situation | Create the order | Buckle inventory | Returns the result | impact |
|---|---|---|---|---|
| 1 | successful | successful | successful | There is no |
| 2 | successful | failure | failure | More inventory, more orders to create |
| 3 | failure | There is no | failure | There is no |
In case 2, why is there a case of multiple withholding inventory when the withholding inventory fails? Because the failure here is divided into two kinds, one is the inventory system really failed to deduct the inventory, the second is the inventory deduction success, may be because of network reasons lead to the order system think that the deduction failed. Details can be learned about the network of two general issues
The order creation approach may have order creation success followed by inventory failure, resulting in order creation without inventory reduction. So this scenario is not appropriate, unless the inventory deduction and order creation are placed in a transaction, which becomes inventory deduction first, if placed in a transaction. The worst case scenario is excessive inventory reduction
Abnormal data processing
You can see that in both scenarios, there will be multiple deductions for inventory, so how to deal with these abnormal data?
1. Inventory table Flow table
- Every time the inventory is deducted, an inventory flow record is generated, and the status is occupied. After the order is paid successfully, the status is changed to release
- Regular inventory reconciliation to scan the inventory flow that has been held for a long time to see if it is due to overholding or unpaid inventory based on the order status, and then cancel those orders
2. Retry + Rollback + alarm + Manual intervention
The above solution still requires maintaining one more inventory table and then modifying the status. If a simpler solution is needed, it is through retry + rollback + alarm + manual intervention.
Based on the scheme, first deduct inventory, then create orders. Instead of state compensation, we add retry, alarm, rollback, and manual intervention
The specific process
And you can see that although it’s still a manual intervention at the end of the day, it’s clear that this is a very practical solution.
However, in extreme cases, there may be a rollback of inventory when the system breaks down or more inventory will be deducted. Secondly, there is no perception of multiple deduction inventory in the first deduction inventory, so it is necessary to add a deduction inventory record table (if there is MQ, a delay message will be sent first), which is not drawn here, because there are too many details to pay attention to
The above process may involve a variety of other operations such as distributed locking, which will not be highlighted here. Because it is primarily a solution for analyzing distributed transactions
For a more secure implementation, a message-based solution, such as RocketMQ’s transaction messages, can be found here
[RocketMQ implementation of reliable message consistency for distributed transactions landing] blog.csdn.net/qq_42651904…
conclusion
Generally distributed transaction solution has a lot of, each solution is suitable for different scenarios, we in solving time still need to combine the use of business to choose specific solutions, not the best solution, only the most suitable Then the most important thing is to remember that all other system calls to check the rollback operation