Redis 分布式锁的正确实现方式，你们公司的有弊端吗？快来改善

在目前的大型互联网公司中，常见的分布式锁的实现方式大概分为三种？

利用数据库条件命中索引实现乐观锁

基于redis的分布式锁

基于zookeeper的分布式锁的实现

当然分布式锁的实现方式有很多，但是不管哪个其底层的设计原则以及思想都是一致，我们分析一下设计分布式锁的几个重点要素。

为了保证分布式锁的完整实现，大概需要满足4个核心的步骤：

① 互斥原则 -->不管在任何的时间段内，只有一个用户线程能够占有其锁的资源。

② 避免死锁的发生 --> 即使说有一个用户线程在持有锁的时候发生异常，不能影响接下来的线程获取锁资源。

③ 容错率问题 --> 这个主要针对是大型项目的集群节点问题，意思就是只要1/2的节点能够正常运行的情况下，那么就能够正常的加锁和释放锁。

④ 解铃还须系铃人 --> 主要的意思就是A线程获取的锁资源只能由线程A去释放此锁资源，客户端的锁资源不能让别人给释放了。

java实现redis分布式锁

引入java针对redis开发依赖

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

coding：实现细节

package com.test.redis;

import redis.clients.jedis.Jedis;

/**
 * redis实现分布式锁的具体实现
 */
public class RedisTemple {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁资源的key值
     * @param requestId 唯一资源用户请求标识
     * @param expireTime 锁员超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;
    }
}

具体代码分析：

String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
这行代码是尝试获取redis锁的实现，大家可以看到有5个参数

lockKey：设置当前redis锁资源的key值，key值在项目中要缺保唯一性

requestId：这个参数可能很多的人都有些迷惑了，因为平时我们在企业中的redis锁的实现，知识存放一个key值就可以了，但是这里为什么要一个value值呢？这个就谈到了我们开始时说的“解铃还须系铃人” requestId我们可以采用 UUID.randomUUID().toString() 去做或者采用其他的业务参数也是可以的。

SET_IF_NOT_EXIST 这个参数是我们redis所需要的参数NX，意思就是 SET IF NOT EXIST 当key值存在的时候就不能set 不存在就set，这个确保了互斥的原则。

SET_WITH_EXPIRE_TIME 这个参数也是我们操作redis需要的，我们给的是PX，意思是我们要给key设置一个超时的事件，集体事件由下一个参数 expireTime 决定。

错误案例：

我们经常能见到的一些错误的redis锁的实现案例。

就是用redis的jedis.setnx()和jedis.expire()组合实现加锁和解锁的操作

public static void getRedisLock(Jedis jedis, String lockKey, String requestId, int expireTime){
        Long result = jedis.setnx(lockKey, requestId);
        if (result == 1) {
            // 此段代码可以看到针对redis的锁实现不是原子操作，如果次处发生异常，那么我们给key加时间就会失败，因此发生死锁
            jedis.expire(lockKey, expireTime);
        }
    }

当然还有很多的错误的案例，在这里就不和大家一一的解析了，只要遵循对的设计原则就是安全的。

接下来我们看一下真正正确的操作是怎样的！

private static final Long RELEASE_SUCCESS = 1L;

/**
 * 释放分布式锁
 * @param jedis 表示redis客户端
 * @param lockKey 锁资源key值
 * @param requestId 唯一性请求标识
 * @return 是否释放成功
 */
public static boolean redisRsleaseLock(Jedis jedis, String lockKey, String requestId) {

    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

    if (RELEASE_SUCCESS.equals(result)) {
        return true;
    }
    return false;

}

上面代码可以分析到，redis锁的释放只需要两行的代码我们就可以搞定了，我们先定义一个Lua的脚本代码，这个大家可以去网上百度一下很多的，其主要就是为了保证此步的操作是原子的操作。

错误的解锁案例

public static void redisRelieaseLock(Jedis jedis, String lockKey, String requestId){
        // 判断加锁与解锁是不是同一个客户端
        if (requestId.equals(jedis.get(lockKey))) {
            // 若在此时，这把锁突然不是这个客户端的，则会误解锁
            jedis.del(lockKey);
        }
    }

好了，在此和大家分享到这里，大家用到时候可以参考一下，具体的细节进行优化即可在正规的项目中去操作了！

关注：编程如此简单一起学习一起成长