[redis realizes seckill service ②] solution to oversold problem

In our last article , Realize the basic business of secsha , But in a concurrent scenario , We will find many problems in the code , Oversold is one of the classic problems . Let's study this thing together .

What is oversold

Oversold is a common phenomenon in seckill business , It means that the user is in the process of purchasing the specified goods , The goods sold exceeded the expectations of the merchants .

How oversold comes into being

If there is only one product left , Just then, two threads enter the red box at the same time , Will enter the updated code together , So there will be oversold .

Graphic oversold

Normal condition

Oversold

Solution

Oversold problem is a typical multi thread security problem , A common solution to this problem is locking ：

• Pessimistic locking
• Optimism lock

Pessimistic locking

Think thread safety problems are bound to happen , Therefore, obtain the lock before operating the data , Ensure that threads execute serially .
for example Synchronized、Lock All belong to pessimistic lock .

Pessimistic concurrency control is actually “ Take the lock first and then visit ” A conservative strategy , For the security of data processing .

But in terms of efficiency , The mechanism of dealing with lock will cause extra cost to the database , And increase the chance of deadlock , At the same time, it will reduce the concurrent performance .

Pessimistic lock implementation ----MySQL edition
Use pessimistic locks , We have to shut it down mysql Auto-commit properties for the database .MySQL By default autocommit Pattern , in other words , When you perform an update operation ,MySQL The results will be submitted immediately . We can use command Settings MySQL For the wrong autocommit Pattern ：set autocommit=0;

// Start business 
begin; 
// Find out the inventory information of goods , Use  for update  Add the lock 
select quantity from items where id=1 for update;
// Modify merchandise inventory 
update items set quantity=100 where id = 1;
// Commit transaction 
commit;

Optimism lock

Think thread safety problems don't necessarily happen , So don't lock , Just judge whether other threads have modified the data when updating the data .

If there is no modification, it is considered safe , Update the data yourself .

If it has been modified by other threads, it indicates that a security problem has occurred , At this point, you can retry or exception .

Compared with pessimistic lock , When processing the database , Optimistic locks do not use the lock mechanism provided by the database . The general way to implement optimistic locking is to record the data version .

Optimistic locks do not produce any locks and deadlocks , Better performance .

The realization of optimistic lock
By a single can be sequentially increasing version Field , You can avoid ABA problem ：

// Search out the product information ,version = 1
select version from items where id=1
// Change the stock of goods to 2
update items set quantity=2,version = 3 where id=1 and version = 2;

except version outside , You can also use time stamps , Because timestamps are naturally sequential .

Reduce optimistic lock strength , Can maximize throughput , Improve concurrency ：

// Modify merchandise inventory 
update item 
set quantity=quantity - 1 
where id = 1 and quantity - 1 > 0

Choose pessimistic lock or optimistic lock

• Optimistic locks are not really locked , Efficient . However , If the granularity of the lock is not well controlled , The probability of update failure will be higher , Prone to business failure .
• Pessimistic lock depends on database lock , Low efficiency . The probability of update failure is low .
• In a highly concurrent business scenario , Pessimistic locks are being used less and less .

In the next chapter, we will specifically implement the optimistic lock scheme .