分布式锁实现方案

分布式锁

服务之间的共享资源，如何保证线程安全
单体，一个jvm，使用synchronized关键字或者lock加锁同步
分布式，多个jvm，使用分布式锁

分布式锁的实现方案？

1. 数据库的方式

创建一张表，字段默认0，t.lock(0) t.lock(0)
上锁，改为1，解锁，改为0

2. redis

setnx命令 set if not exist 不存在则设置成功，否则失败
上锁：成功执行setnx key value 解锁：delete key
避免死锁：设置key的有效时间 expire key 10
要将两个操作变成一个原子操作
4.0之前，使用lua脚本
4.0之后，使用现成的原子指令，在设置数据的同时，设置有效期
避免无锁 释放锁的时候判断锁是不是我上的锁 value来判断

参照redis做分布式锁资料

redis，redission

public class RedisTool {
    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 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
        String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;
    }
}

可以看到，我们加锁就一行代码：jedis.set(String key, String value, String nxxx, String
expx, int time)，这个set()方法一共有五个形参：
第一个为key，我们使用key来当锁，因为key是唯一的。
第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：
1.当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。
2. 已有锁存在，不做任何操作。

public class RedisTool {
    private static final Long RELEASE_SUCCESS = 1L;
    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(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;
    }
}

可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码。第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。

可重入性及锁续期没有实现，通过redisson解决（类似AQS的实现，看门狗监听机制）。
Redisson使用lua脚本加锁处理，异步加锁，锁续命30s（循环嵌套调用自己，每次10s）

主从模式下有问题
还没异步同步给从节点时主节点挂掉了 或主从同步延迟 哨兵延迟
zookeeper没这个问题 选举leader 保证了AP 强一致性
解决方案 ，1.主从同步设置成同步的。
2.redLock 超过半数以上的redis节点加锁成功才算加锁成功 类似zookeeper
redlock存在问题较多 如加锁回滚之类的 影响性能

redlock：意思的机制都只操作单节点、即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况（redis同步设置可能数据丢失）。redlock从多个节点申请锁，当一半以上节点获取成功、锁才算获取成功，redission有相应的实现。

高并发场景下提高分布式锁的性能
缩小锁的粒度 例如concurrentHashMap分段锁 的实现
如库存200 分成10个key 每个key20个库存 使用不同段位的key来减库存 性能提升10倍

3. zookeeper

以节点为锁，创建成功，上锁成功 解锁，删除节点
避免死锁：使用临时节点，客户端如果挂掉，会自动删除。
避免羊群效应：使用有序节点

单机，redis的性能没问题，集群的话，zk的一致性高，更可靠