How to reduce inventory with high concurrency on the Internet

The inventory quantity model used in this paper

This article is for the convenience of description , We use a simplified inventory quantity model , The actual inventory quantity items can be designed according to actual needs .

Inventory quantity table -stockNum

Field name	English name	Field type
Commodity logo	skuId	Long integer
Inventory quantity	num	Integers

The traditional database guarantees that it will not oversold

adopt Sql Judge whether the remaining inventory is enough , Multiple concurrent executions update Only one statement can execute successfully .

Update stockNum set num=num- Order quantity where skuId= goods ID and num- Order quantity >0

This method is not the focus of this article , Use the database to make quantity deduction , In the face of high concurrency, there is no way to resist , Let's next design a way to use Redis Cache the scheme for inventory deduction .

PS: The high concurrency of inventory deduction cannot be fundamentally solved by dividing the warehouse and table , Because the sub warehouse and sub table are based on commodities , High concurrency during promotion is aimed at a small number of goods , Even a commodity , Finally, the concurrent traffic will be sent to a few tables , Sub database and sub table will not work , You can only improve the concurrency of a single partition .

Redis The principle of deduction

Inventory deduction actually includes two parts , Part I oversold verification , The second part is the final deduction of inventory ; In traditional database deduction , The two were completed together , At the same time, oversold verification has been completed （where The judgment in the book ） And deductions （update Number ）; If we want to solve these two parts , We need to solve the two problems separately ：

The first level is to solve the oversold inspection ： We can put the data into Redis in , Every time you deduct inventory , All the Redis The data in incryby Deduction , If the number returned is greater than 0, Indicates that the inventory is sufficient , because Redis A single thread , You can trust the returned results . The first level is Redis, It can resist high concurrency , performance Ok. After the oversold verification is passed , Enter the second level .

The second step is to reduce inventory ： After the first level , The second level does not need to judge whether the quantity is enough , You just need a fool to deduct inventory , Execute the following statement on the database ：

Update stockNum set num=num- Order quantity where skuId= goods ID

Here comes the question , Here, because the database is divided into warehouses and tables by commodities , The concurrency has not decreased , Isn't the problem unsolved ？ Yes , There is also a need to introduce a heavyweight weapon , Task library , We do not directly execute the above deduction statement on the business database , We only record this deduction task in the task library , Then deduct asynchronously . The task library uses the order number or other fields that can be hashed to divide the warehouse and table , In this way, different orders for the same commodity will be hashed in different inventories of the task library , Although it's still database tolerance , But database hotspots have been eliminated .

The overall structure is as follows ：

 

Quantity verification and data persistence are separated ,Redis The cache is responsible for verifying the quantity , Asynchronous tasks are responsible for data persistence .

In subsequent articles , I will introduce the design of task library , The task library can not only do the final consistency of data , It can also be used as a state machine engine to support the state machine , Serve the state machine business .