Lock tips under high concurrency scenarios

How to ensure a method, or a block of code under high concurrency, at the same time can only be one thread execution, single application can use the API concurrent processing related to control, but the single application architecture evolved into a distributed micro-service architecture, the cross examples of the deployment process, it is clear there is no way to control concurrent application layer through the mechanism of the lock. So what are the type of lock, why use locks, lock usage scenarios What? Today we chat tips lock in high concurrency scenarios.

Lock category

　　Requirements for different application scenarios locks vary, let's look at what are the lock category, what is the difference between these locks.

• Pessimistic lock (synchronize)
  • Java heavyweight lock synchronize
  • Database row lock
• Optimistic locking
  • Lightweight lock volatile and CAS Java in
  • Database version number
• Distributed Lock (Redis lock)

Optimistic locking

　　Like saying that you are a positive optimistic attitude to life of people, to always think the best of circumstances, such as every time you get to share data when no one else would think to modify, so it will not be locked, but in updates will determine when you have no one to update the data during this period.

　　Optimistic locking using the former, after the determination. We look at pseudo-code:

reduce()
{
    select total_amount from table_1
    if(total_amount < amount ){
          return failed.  
    }  
    //其他业务逻辑
    update total_amount = total_amount - amount where total_amount > amount; 
}

• The version number of the database belonging to the LEGO lock;
• CAS algorithms implemented by class belong optimistic locking.

Pessimistic locking

　　Pessimistic locking is how to understand it? Just turn the lock is relatively optimistic, always assume the worst-case scenario, assuming that every time you take the time data can be modified by other people, so you each time he shared data will add a lock, so you ran out then release the lock, to give others the use of data.

　　Analyzing the front pessimistic locking, after use. We also look at pseudo-code:

the reduce () 
{ 
    // Other business logic 
    int NUM = TOTAL_AMOUNT = TOTAL_AMOUNT Update - AMOUNT WHERE TOTAL_AMOUNT> AMOUNT; 
　　  IF (NUM == . 1 ) {
           // business logic.   
    } 
}

• synchronize Java is a heavyweight in the lock, are pessimistic locking;
• Database row locks belong pessimistic locking;

Deductions in Action

　　To give a very common example, the balance of deductions under high concurrency, or similar goods inventory deductions, may be balance fund account deductions. Deductions operating what will happen then? It is easy to see that the issue may occur are deducted due to oversold , which is deducted become negative.

　　For example, like my inventory data only 100. Paragraph 1 pen concurrency request to sell 100, sell a second batch of 100 yuan, resulting in the current inventory quantity is negative. How to encounter such a scenario should break it? Here are four scenarios.

Scheme 1: synchronous exclusive lock

　　This time it is easy to think of the most simple solution: Synchronization exclusive lock (synchronize). But the disadvantage exclusive lock is obvious:

• One drawback is that performance problems caused by the thread serial, performance overhead is relatively large.
• Another disadvantage is that the problem can not be solved under cross-process distributed deployment;

Scenario 2: Database row lock

　　Second, we might think that the database row lock to lock this data, this approach compared to the exclusive lock to solve the problem of cross-process, but there are still shortcomings.

• One drawback is that performance problems, would have been blocked at the database level, until the transaction commits, here is the serial execution;
• The second caveat set the transaction isolation level is Read Committed, or concurrent cases, other transactions can not see the data submitted, will still result in oversold issues;
• Third, the disadvantage easy playing a database connection, if there is a third party interface interaction affairs (timeout possibility), will lead to connect this transaction has been blocked, played a database connection.
• The last drawback, prone to cross deadlock, if the parental lock control a plurality of traffic well, recorded two cross AB deadlock occurs.

Program 3: redis Distributed Lock

　　On the front of the solutions of the database is to be used as a distributed lock, so the same token, redis, zookeeper are the equivalent of A lock database, in fact, when faced with a problem lock, the code itself or whether it is synchronize the various lock use are more complex, so the idea is to ask the code to handle the problem of consistency to a consistency that can help you deal with problems of professional components, such as databases, such as redis, such as zookeeper and so on.

　　Here we analyze the advantages and disadvantages of distributed locks:

• advantage:
  • We can avoid a lot of exclusive lock on the database of expropriation, improve the response capacity of the system ;
• Disadvantages:
  • And set the lock timeout settings atomicity;
  • Timeout disadvantage is not provided;
  • Service downtime or circumstances thread blocking timeouts;
  • Timeout unreasonable situation;

Locking and expiration settings of atomicity

　　redis SETNX lock command, set the expiration time is The expire lock, unlock command is del, but the previous version 2.6.12, locking and lock setting command is expired two operations do not have atomic. If setnx after you set up key-value, has not had time to use to set the expiration time expire, the current thread hung up or thread is blocked, the current thread will lead to key settings remain in effect, follow the thread can not use normal setnx acquire the lock, resulting in death lock.

　　To address this issue, more than redis2.6.12 version adds an optional parameter, you can set an expiration time key in the lock at the same time, to ensure the locking and expiration operations atomic.

　　But even solve the problem of atomicity, will face the same extreme on business issues, such as distributed environment, after obtaining A to lock because thread A business code takes too long, leading to lock timeout, lock automatically lapse. Subsequent thread B holds the lock of the accident, after thread A again resumes directly with the del command to release the lock, so that the same mistakes will thread B Key lock accidentally deleted. Code that takes a long time is quite common scenario, if your code calls external communication interface, it is easy to produce such a scenario.

When you set a reasonable length

　　Case timeout thread blocked just mentioned, so long, of course, does not work if you do not set up, if the process thread holds the lock of a sudden service is down, so the lock will never fail. The same also lock timeout if there is a reasonable question, if you set the hold time is too long will affect the performance, if the set time is too short, it is possible to deal with traffic congestion is not completed, whether it is reasonable to set the lock time?

Xiaoxuming lock

　　This is a very easy problem to solve, but there is a way to solve this problem, and that is prolonging the lock, we can give a lock timeout settings, and then start a daemon thread, the thread back to let the guard after a period of time set the lock timeout, lock the implementation process continued life is to write a daemon thread, and then to judge the case of the object lock, when the fast failure, once again re-locking, but must be subject to the same lock judge, not chaos continued.

　　Similarly, the main thread business execution is over, the guardian of the thread also need to be destroyed to avoid waste of resources, the use of prolonging lock solution is relatively in terms of more complex, so if the business is relatively simple, according to the timeout experience analogy, reasonable to set the lock on the line .

Scenario 4: Database optimistic locking

　　Database optimistic locking lock of a principle is to try to find ways to reduce the scope of the lock. The larger the range of the lock, the worse the performance, the lock on the database is reduced to a minimum lock range. We look at the following pseudo-code

reduce()
{
    select total_amount from table_1
    if(total_amount < amount ){
          return failed.  
    }  
    //其他业务逻辑
    update total_amount = total_amount - amount;  
}

 　　We can see the code before the amendment is not where conditions. After the modification, where the condition is determined together: deductions to be greater than the total inventory stock.

update total_amount = total_amount - amount where total_amount > amount

　　If the update article number returns 0, indicating that the implementation process is preempted by other threads deductions, deductions and avoid the negative.

　　However, this scheme will involve a problem if the code in the previous update, as well as other business logic in some other database write operation, then how to roll back this part of the data it?

　　My suggestion is this, you can select the following two writing:

• Use transaction rollback wording:

　　We give way to increase business affairs, the method throws an exception when deductions affect the number of zero inventory, so to him before the business code will be rolled back.

reduce()
{
    select total_amount from table_1
    if(total_amount < amount ){
          return failed.  
    }  
    //其他业务逻辑
    int num = update total_amount = total_amount - amount where total_amount > amount; 
　　if(num==0) throw Exception;
}

• The second wording

the reduce () 
{ 
    // Other business logic 
    int NUM = TOTAL_AMOUNT = TOTAL_AMOUNT Update - AMOUNT WHERE TOTAL_AMOUNT> AMOUNT; 
　　 IF (NUM ==. 1 ) { 
          // business logic .   
    } {the else 
　　　　the throw Exception; 
　　} 
}

　　First update business logic execution, if execution was successful again perform logical operations, this solution is relatively My proposed solution. In the case of concurrent operations on the shared resource deductions you can use this method, but there is a need leads to problems, such as in case of other business logic in the business, because of special reason for the failure of how to do it? For example, in the process of deduction OOM service how to do?

　　I can only say that these very extreme cases, such as suddenly lost all data center downtime, which in rare cases can only manual intervention, if all the extreme cases are taken into account, is not realistic. The focus of our discussion is complicated by the situation, how to operate a shared resource locking problems.

to sum up

　　Finally, I come to you to sum up, if you can be very skilled to solve such problems, the first time certainly thought was: Database version number of solutions or distributed lock solution; but if you are a beginner, I believe you the first time will take into account synchronization database row lock or lock in Java provides.

　　The purpose of today's discussion is hoped that this scene of several lock into a particular scene, and gradually to compare and analyze, so you can understand the ins and outs of using a more comprehensive system of locks to this problem. I Zhangfei Hong, I hope I can share to help you.