What I want to share with you today is Distributed Lock. This article uses five cases, diagrams, source code analysis, etc. to analyze.

Common synchronized, Lock and other locks are all implemented based on a single JVM. What should we do in a distributed scenario? At this time, distributed locks appeared.

Regarding distributed implementation solutions, there are three popular ones in the industry:

1, based on database

2, based on Redis

3. Based on Zookeeper

In addition, there are also implementations using etcd and consul.

The two most commonly used solutions in development are Redis and Zookeeper, and the most complex of the two solutions and the most likely to cause problems is Redis implementation plan, so today we will talk about the Redis implementation plan.

Main content of this article

##Distributed lock scenario

Case 1

@RestController
public class IndexController {

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    /**
     * 模擬下單減庫存的場(chǎng)景
     * @return
     */
    @RequestMapping(value = "/duduct_stock")
    public String deductStock(){
        // 從redis 中拿當(dāng)前庫存的值
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
        if(stock > 0){
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock",realStock + "");
            System.out.println("扣減成功，剩余庫存：" + realStock);
        }else{
            System.out.println("扣減失敗，庫存不足");
        }
        return "end";
    }
}

Redis The value is 100.

int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));

這行代碼，獲取到的值都為100，緊跟著判斷大于0后都進(jìn)行-1操作，最后設(shè)置到redis 中的值都為99。但正常執(zhí)行完成后redis中的值應(yīng)為 95。

案例2-使用synchronized 實(shí)現(xiàn)單機(jī)鎖

在遇到案例1的問題后，大部分人的第一反應(yīng)都會(huì)想到加鎖來控制事務(wù)的原子性，如下代碼所示：

@RequestMapping(value = "/duduct_stock")
public String deductStock(){
    synchronized (this){
        // 從redis 中拿當(dāng)前庫存的值
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
        if(stock > 0){
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock",realStock + "");
            System.out.println("扣減成功，剩余庫存：" + realStock);
        }else{
            System.out.println("扣減失敗，庫存不足");
        }
    }
    return "end";
}

現(xiàn)在當(dāng)有多個(gè)請(qǐng)求訪問該接口時(shí)，同一時(shí)刻只有一個(gè)請(qǐng)求可進(jìn)入方法體中進(jìn)行庫存的扣減，其余請(qǐng)求等候。

但我們都知道，synchronized 鎖是屬于JVM級(jí)別的，也就是我們俗稱的“單機(jī)鎖”。但現(xiàn)在基本大部分公司使用的都是集群部署，現(xiàn)在我們思考下以上代碼在集群部署的情況下還能保證庫存數(shù)據(jù)的一致性嗎？

答案是不能，如上圖所示，請(qǐng)求經(jīng)Nginx分發(fā)后，可能存在多個(gè)服務(wù)同時(shí)從Redis中獲取庫存數(shù)據(jù)，此時(shí)只加synchronized （單機(jī)鎖）是無效的，并發(fā)越高，出現(xiàn)問題的幾率就越大。

案例3-使用SETNX實(shí)現(xiàn)分布式鎖

setnx：將 key 的值設(shè)為 value，當(dāng)且僅當(dāng) key 不存在。

若給定 key 已經(jīng)存在，則 setnx 不做任何動(dòng)作。

使用setnx實(shí)現(xiàn)簡(jiǎn)單的分布式鎖：

/**
 * 模擬下單減庫存的場(chǎng)景
 * @return
 */
@RequestMapping(value = "/duduct_stock")
public String deductStock(){
    String lockKey = "product_001";
    // 使用 setnx 添加分布式鎖
    // 返回 true 代表之前redis中沒有key為 lockKey 的值，并已進(jìn)行成功設(shè)置
    // 返回 false 代表之前redis中已經(jīng)存在 lockKey 這個(gè)key了
    Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "wangcp");
    if(!result){
        // 代表已經(jīng)加鎖了
        return "error_code";
    }

    // 從redis 中拿當(dāng)前庫存的值
    int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
    if(stock > 0){
        int realStock = stock - 1;
        stringRedisTemplate.opsForValue().set("stock",realStock + "");
        System.out.println("扣減成功，剩余庫存：" + realStock);
    }else{
        System.out.println("扣減失敗，庫存不足");
    }

    // 釋放鎖
    stringRedisTemplate.delete(lockKey);
    return "end";
}

我們知道 Redis 是單線程執(zhí)行，現(xiàn)在再看案例2中的流程圖時(shí)，哪怕高并發(fā)場(chǎng)景下多個(gè)請(qǐng)求都執(zhí)行到了setnx的代碼，redis會(huì)根據(jù)請(qǐng)求的先后順序進(jìn)行排列，只有排列在隊(duì)頭的請(qǐng)求才能設(shè)置成功。其它請(qǐng)求只能返回“error_code”。

當(dāng)setnx設(shè)置成功后，可執(zhí)行業(yè)務(wù)代碼對(duì)庫存扣減，執(zhí)行完成后對(duì)鎖進(jìn)行釋放。

我們?cè)賮硭伎枷乱陨洗a已經(jīng)完美實(shí)現(xiàn)分布式鎖了嗎？能夠支撐高并發(fā)場(chǎng)景嗎？答案并不是，上面的代碼還是存在很多問題的，離真正的分布式鎖還差的很遠(yuǎn)。

我們分析一下，上面的代碼存在的問題：

死鎖：假如第一個(gè)請(qǐng)求在setnx加鎖完成后，執(zhí)行業(yè)務(wù)代碼時(shí)出現(xiàn)了異常，那釋放鎖的代碼就無法執(zhí)行，后面所有的請(qǐng)求也都無法進(jìn)行操作了。

針對(duì)死鎖的問題，我們對(duì)代碼再次進(jìn)行優(yōu)化，添加try-finally，在finally中添加釋放鎖代碼，這樣無論如何都會(huì)執(zhí)行釋放鎖代碼，如下所示：

/**
     * 模擬下單減庫存的場(chǎng)景
     * @return
     */
@RequestMapping(value = "/duduct_stock")
public String deductStock(){
    String lockKey = "product_001";

    try{
        // 使用 setnx 添加分布式鎖
        // 返回 true 代表之前redis中沒有key為 lockKey 的值，并已進(jìn)行成功設(shè)置
        // 返回 false 代表之前redis中已經(jīng)存在 lockKey 這個(gè)key了
        Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "wangcp");
        if(!result){
            // 代表已經(jīng)加鎖了
            return "error_code";
        }
        // 從redis 中拿當(dāng)前庫存的值
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
        if(stock > 0){
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock",realStock + "");
            System.out.println("扣減成功，剩余庫存：" + realStock);
        }else{
            System.out.println("扣減失敗，庫存不足");
        }
    }finally {
        // 釋放鎖
        stringRedisTemplate.delete(lockKey);
    }

    return "end";
}

經(jīng)過改進(jìn)后的代碼是否還存在問題呢？我們思考正常執(zhí)行的情況下應(yīng)該是沒有問題，但我們假設(shè)請(qǐng)求在執(zhí)行到業(yè)務(wù)代碼時(shí)服務(wù)突然宕機(jī)了，或者正巧你的運(yùn)維同事重新發(fā)版，粗暴的 kill -9 掉了呢，那代碼還能執(zhí)行 finally 嗎？

案例4-加入過期時(shí)間

針對(duì)想到的問題，對(duì)代碼再次進(jìn)行優(yōu)化，加入過期時(shí)間，這樣即便出現(xiàn)了上述的問題，在時(shí)間到期后鎖也會(huì)自動(dòng)釋放掉，不會(huì)出現(xiàn)“死鎖”的情況。

@RequestMapping(value = "/duduct_stock")
public String deductStock(){
    String lockKey = "product_001";

    try{
        Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey,"wangcp",10,TimeUnit.SECONDS);
        if(!result){
            // 代表已經(jīng)加鎖了
            return "error_code";
        }
        // 從redis 中拿當(dāng)前庫存的值
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
        if(stock > 0){
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock",realStock + "");
            System.out.println("扣減成功，剩余庫存：" + realStock);
        }else{
            System.out.println("扣減失敗，庫存不足");
        }
    }finally {
        // 釋放鎖
        stringRedisTemplate.delete(lockKey);
    }

    return "end";
}

現(xiàn)在我們?cè)偎伎家幌拢o鎖加入過期時(shí)間后就可以了嗎？就可以完美運(yùn)行不出問題了嗎？

超時(shí)時(shí)間設(shè)置的10s真的合適嗎？如果不合適設(shè)置多少秒合適呢？如下圖所示

Assume there are three requests at the same time.

• Request 1 needs to be executed for 15 seconds after being locked first, but the lock becomes invalid and released after 10 seconds of execution.
• Request 2 is locked and executed after entering. When request 2 is executed for 5 seconds, request 1 is executed and the lock is released, but the lock of request 2 is released at this time.
• Request 3 starts executing when request 2 is executed for 5 seconds, but when request 2 is executed for 3 seconds, the lock of request 3 is released.

We can see the problem by just simulating 3 requests now. If it is in a truly high-concurrency scenario, the lock may face "always invalid" or "permanent invalid".

So where is the specific problem? The summary is as follows:

• 1. When there is a request to release the lock, the lock released is not your own lock
• 2. The timeout period has expired Short, the existing code will be automatically released before it is executed

We think about the corresponding solutions to the problem:

• For question 1, we think of Generate a unique id when the request comes in, use this unique id as the value of the lock, obtain and compare first when releasing, and then release when the comparison is the same, this can solve the problem of releasing other request locks.
• Regarding question 2, is it really appropriate for us to think about continuously extending the expiration time? If the setting is too short, there will be a problem of automatic release over time. If the setting is too long, there will be a problem that the lock cannot be released for a period of time after a shutdown, although "deadlock" will no longer occur. How to solve this problem?

Case 5-Redisson distributed lock

Spring BootIntegrationRedissonSteps

引入依賴

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.6.5</version>
</dependency>

初始化客戶端

@Bean
public RedissonClient redisson(){
    // 單機(jī)模式
    Config config = new Config();
    config.useSingleServer().setAddress("redis://192.168.3.170:6379").setDatabase(0);
    return Redisson.create(config);
}

Redisson實(shí)現(xiàn)分布式鎖

@RestController
public class IndexController {

    @Autowired
    private RedissonClient redisson;
    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    /**
     * 模擬下單減庫存的場(chǎng)景
     * @return
     */
    @RequestMapping(value = "/duduct_stock")
    public String deductStock(){
        String lockKey = "product_001";
        // 1.獲取鎖對(duì)象
        RLock redissonLock = redisson.getLock(lockKey);
        try{
            // 2.加鎖
            redissonLock.lock();  // 等價(jià)于 setIfAbsent(lockKey,"wangcp",10,TimeUnit.SECONDS);
            // 從redis 中拿當(dāng)前庫存的值
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
            if(stock > 0){
                int realStock = stock - 1;
                stringRedisTemplate.opsForValue().set("stock",realStock + "");
                System.out.println("扣減成功，剩余庫存：" + realStock);
            }else{
                System.out.println("扣減失敗，庫存不足");
            }
        }finally {
            // 3.釋放鎖
            redissonLock.unlock();
        }
        return "end";
    }
}

Redisson 分布式鎖實(shí)現(xiàn)原理圖

Redisson 底層源碼分析

我們點(diǎn)擊lock()方法，查看源碼，最終看到以下代碼

<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        internalLockLeaseTime = unit.toMillis(leaseTime);

        return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
                  "if (redis.call(&#39;exists&#39;, KEYS[1]) == 0) then " +
                      "redis.call(&#39;hset&#39;, KEYS[1], ARGV[2], 1); " +
                      "redis.call(&#39;pexpire&#39;, KEYS[1], ARGV[1]); " +
                      "return nil; " +
                  "end; " +
                  "if (redis.call(&#39;hexists&#39;, KEYS[1], ARGV[2]) == 1) then " +
                      "redis.call(&#39;hincrby&#39;, KEYS[1], ARGV[2], 1); " +
                      "redis.call(&#39;pexpire&#39;, KEYS[1], ARGV[1]); " +
                      "return nil; " +
                  "end; " +
                  "return redis.call(&#39;pttl&#39;, KEYS[1]);",
                    Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
}

沒錯(cuò)，加鎖最終執(zhí)行的就是這段lua 腳本語言。

if (redis.call('exists', KEYS[1]) == 0) then 
    redis.call('hset', KEYS[1], ARGV[2], 1); 
    redis.call('pexpire', KEYS[1], ARGV[1]); 
    return nil; 
end;

腳本的主要邏輯為：

• exists 判斷 key 是否存在
• 當(dāng)判斷不存在則設(shè)置 key
• 然后給設(shè)置的key追加過期時(shí)間

這樣來看其實(shí)和我們前面案例中的實(shí)現(xiàn)方法好像沒什么區(qū)別，但實(shí)際上并不是。

這段lua腳本命令在Redis中執(zhí)行時(shí)，會(huì)被當(dāng)成一條命令來執(zhí)行，能夠保證原子性，故要不都成功，要不都失敗。

我們?cè)谠创a中看到Redssion的許多方法實(shí)現(xiàn)中很多都用到了lua腳本，這樣能夠極大的保證命令執(zhí)行的原子性。

下面是Redisson鎖自動(dòng)“續(xù)命”源碼：

private void scheduleExpirationRenewal(final long threadId) {
    if (expirationRenewalMap.containsKey(getEntryName())) {
        return;
    }

    Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
        @Override
        public void run(Timeout timeout) throws Exception {

            RFuture<Boolean> future = commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
                                                                     "if (redis.call(&#39;hexists&#39;, KEYS[1], ARGV[2]) == 1) then " +
                                                                     "redis.call(&#39;pexpire&#39;, KEYS[1], ARGV[1]); " +
                                                                     "return 1; " +
                                                                     "end; " +
                                                                     "return 0;",
                                                                     Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));

            future.addListener(new FutureListener<Boolean>() {
                @Override
                public void operationComplete(Future<Boolean> future) throws Exception {
                    expirationRenewalMap.remove(getEntryName());
                    if (!future.isSuccess()) {
                        log.error("Can&#39;t update lock " + getName() + " expiration", future.cause());
                        return;
                    }

                    if (future.getNow()) {
                        // reschedule itself
                        scheduleExpirationRenewal(threadId);
                    }
                }
            });
        }
    }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);

    if (expirationRenewalMap.putIfAbsent(getEntryName(), task) != null) {
        task.cancel();
    }
}

這段代碼是在加鎖后開啟一個(gè)守護(hù)線程進(jìn)行監(jiān)聽。Redisson超時(shí)時(shí)間默認(rèn)設(shè)置30s，線程每10s調(diào)用一次判斷鎖還是否存在，如果存在則延長(zhǎng)鎖的超時(shí)時(shí)間。

現(xiàn)在，我們?cè)倩剡^頭來看看案例5中的加鎖代碼與原理圖，其實(shí)完善到這種程度已經(jīng)可以滿足很多公司的使用了，并且很多公司也確實(shí)是這樣用的。但我們?cè)偎伎枷率欠襁€存在問題呢？例如以下場(chǎng)景：

• As we all knowRedis is deployed in a cluster in actual deployment and use. In high concurrency scenarios, we lock. After writing the key to the master node, the master still The master went down when it was not synchronized to the slave node. The original slave node became the new master node after election. At this time, the lock failure problem may occur.
• Through the implementation mechanism of distributed locks, we know that in high concurrency scenarios, only successfully locked requests can continue to process business logic. Then everyone comes to lock, but only one lock is successful, and the rest are waiting. In fact, distributed locks and high concurrency are semantically contradictory. Although our requests are all concurrent, Redis helps us queue the requests for execution, which means converting our parallelism into serialization. . There will definitely be no concurrency problems in serially executed code, but the performance of the program will definitely be affected.

In response to these problems, we are thinking about solutions again

• Thinking When solving the problem, we first think of the CAP principle (consistency, availability, partition tolerance), then the current Redis satisfies AP (availability, partition tolerance). If we want to solve this problem, we need to find A distributed system that meets CP (consistency, partition fault tolerance). The first thing that comes to mind is Zookeeper. The inter-cluster data synchronization mechanism of Zookeeper is that when the master node receives the data, it will not immediately return a successful feedback to the client. It will first communicate with the child node. Synchronization, the client will be notified of successful reception only after more than half of the nodes have completed synchronization.And if the master node goes down, the re-elected master node according to the Zab protocol of Zookeeper (Zookeeper atomic broadcast) must have been successfully synchronized.

  Then the question is, how do we choose between Redisson and Zookeeper distributed locks? The answer is that if the amount of concurrency is not that high, you can use Zookeeper to do distributed locks, but its concurrency capability is far inferior to Redis. If you have relatively high concurrency requirements, then use Redis. The occasional master-slave architecture lock failure problem is actually tolerable.

• Regarding the second issue of improving performance, we can refer to the idea of ??lock segmentation technology of ConcurrentHashMap, such as the inventory of our code The amount is currently 1000, then we can divide it into 10 segments, each segment is 100, and then lock each segment separately, so that the locking and processing of 10 requests can be performed at the same time. Of course, students who have requirements can continue to subdivide. But in fact, the Qps of Redis has reached 10W , which is completely sufficient in scenarios without particularly high concurrency.