分布式锁Redis Zookeeper

别人面试总结

循序渐进zookeeper

分布式锁之Zookeeper

https://www.cnblogs.com/xuwc/p/14019932.html

Zookeeper的应用-分布式锁

有部分代码redis

分布式锁之Redis

Java原生的锁机制弊端

某些场景在分布式部署系统的情况下，两个系统，运行在两个不同的JVM里面，他们加的锁只对属于自己JVM里面的线程有效，对于其他JVM的线程是无效的，因此Java原生的锁机制无法保证线程安全，所以我们需要用到分布式锁。

分布式锁原理

zookeeper分布式锁原理

面试 ZK（ZooKeeper）分布式锁实现

常见的分布式锁实现方案里面，除了使用redis来实现之外，使用zookeeper也可以实现分布式锁。在介绍zookeeper(下文用zk代替)实现分布式锁的机制之前，先粗略介绍一下zk是什么东西：Zookeeper是一种提供配置管理、分布式协同以及命名的中心化服务。zk的模型是这样的：zk包含一系列的节点，叫做znode，就好像文件系统一样每个znode表示一个目录，然后znode有一些特性：

有序节点：假如当前有一个父节点为/lock，我们可以在这个父节点下面创建子节点；
zookeeper提供了一个可选的有序特性，例如我们可以创建子节点“/lock/node-”并且指明有序，那么zookeeper在生成子节点时会根据当前的子节点数量自动添加整数序号
也就是说，如果是第一个创建的子节点，那么生成的子节点为/lock/node-0000000000，下一个节点则为/lock/node-0000000001，依次类推。

临时节点：客户端可以建立一个临时节点，在会话结束或者会话超时后，zookeeper会自动删除该节点。

事件监听：在读取数据时，我们可以同时对节点设置事件监听，当节点数据或结构变化时，zookeeper会通知客户端。当前zookeeper有如下四种事件：

节点创建 节点删除 节点数据修改 子节点变更

基于以上的一些zk的特性，我们很容易得出使用zk实现分布式锁的落地方案：

1. 使用zk的临时节点和有序节点，每个线程获取锁就是在zk创建一个临时有序的节点，比如在/lock/目录下。
2. 创建节点成功后，获取/lock目录下的所有临时节点，再判断当前线程创建的节点是否是所有的节点的序号最小的节点
3. 如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。
4. 如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前一个节点添加一个事件监听。

比如当前线程获取到的节点序号为/lock/003,然后所有的节点列表为[/lock/001,/lock/002,/lock/003],则对/lock/002这个节点添加一个事件监听器。

如果锁释放了，会唤醒下一个序号的节点，然后重新执行第3步，判断是否自己的节点序号是最小。比如/lock/001释放了，/lock/002监听到时间，此时节点集合为[/lock/002,/lock/003],则/lock/002为最小序号节点，获取到锁。整个过程如下：

zk节点从一个维度分为永久节点和临时节点，从另一个维度分为无序节点和有序节点。 简单来说：

1. 当zk判断client的连接timeout时，会主动删除该client的所有临时节点；
2. 有序节点会按照节点创建时间生成一个序列号，该序号可以用于排序。

据此，zk使用临时有序节点来作为分布式锁的承载者：

1. 利用有序的特性决定谁是锁的拥有者；
2. 利用client连接断开会删除临时节点的特性来防止死锁。

1. 由于节点有序，因此通过后一个节点watch前一个节点删除的监控机制实现公平锁的同时避免了惊群效应；
2. 利用抢占建立临时节点并watch此节点，当此节点删除时，抢占建立新临时节点的方式实现非公平锁。

当thread1释放锁，序号为全0的临时节点销毁，thread2由于watch了全0节点，所以thread2可以知道全0节点删除，此时thread2变成了锁持有者，此时thread3不会收到通知也无需做任何操作。

此外，zk是CP导向，在集群故障时可靠性更好，但速度较慢。
Consistency 一致性
Partition tolerance 分区容错性

Redis分布式锁原理

使用Redis做分布式锁的思路：
在redis中设置一个值表示加了锁，然后释放锁的时候就把这个key删除

1 SET key value NX PX milliseconds

value要具有唯一性，避免删除别人的锁 SET if Not Exists 设置过期时间避免死锁
基于redis组成的分布式锁解决方案为：
• setNx一个锁key，相应的value为当前时间加上过期时间的时钟；
• 如果setNx成功，或者当前时钟大于此时key对应的时钟则加锁成功，否则加锁失败退出；
• 加锁成功执行相应的业务操作（处理共享数据源）；
• 释放锁时判断当前时钟是否小于锁key的value，如果当前时钟小于锁key对应的value则执行删除锁key的操作。

2 RedLock - Redis官方提出的一种分布式锁的算法

只要 2N+1 个节点加锁成功，那么就认为获取了锁， 解锁时将所有实例解锁

获取当前时间戳，单位是毫秒
轮流尝试在每个master节点上创建锁，过期时间设置较短，一般就几十毫秒
尝试在大多数节点上建立一个锁，比如5个节点就要求是3个节点（n / 2 +1）
客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了
要是锁建立失败了，那么就依次删除这个锁
只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁
结论：这种算法还是颇具争议的，可能还会存在不少的问题，无法保证加锁的过程一定正确

3 Redisson

redis通过抢占设置数据的方式实现分布式锁，查询对应的key是否存在，若存在则判断是否是本线程创建，若是本线程创建，则计数加1，表示重入，否则获取锁失败。

其中KEYS[1]是锁名称，ARGV[1]是超时时间，ARGV[2]是uuid:线程id。redis分布式锁数据结构是>，其中key是锁名称，对应上面的KEYS[1]，key1是uuid:线程id，用以确认锁的拥有者，对应上面的ARGV[2]，value表示重入次数，所以与zk的分布式锁一样，重入几次就需要释放几次。
为了确保查询、set的原子性，redisson使用了lua脚本。
为了防止死锁，若用户没有设置锁的持有时间，则redisson默认给予30秒的超时时间，并在30秒到期前续租30秒，直到用户调用释放锁的方法。若用户没有释放锁就挂掉，则30秒后锁数据会超时老化，从而防止了死锁。
redis分布式锁默认是非公平锁，公平锁在非公平锁基础上采用队列排序的方式实现。

String uuid = xxxx;
// 伪代码，具体实现看项目中用的连接工具
// 有的提供的方法名为set 有的叫setIfAbsent
set Test uuid NX PX 3000
try{
// biz handle....
} finally {
    // unlock
    if(uuid.equals(redisTool.get('Test')){
        redisTool.del('Test');
    }
}

-- lua删除锁：
-- KEYS和ARGV分别是以集合方式传入的参数，对应上文的Test和uuid。
-- 如果对应的value等于传入的uuid。
if redis.call('get', KEYS[1]) == ARGV[1] 
    then 
    -- 执行删除操作
        return redis.call('del', KEYS[1]) 
    else 
    -- 不成功，返回0
        return 0 
end

• redisson所有指令都通过lua脚本执行，redis支持lua脚本原子性执行

• redisson设置一个key的默认过期时间为30s,如果某个客户端持有一个锁超过了30s怎么办？

  redisson中有一个watchdog的概念，翻译过来就是看门狗，它会在你获取锁之后，每隔10秒帮你把key的超时时间设为30s
  这样的话，就算一直持有锁也不会出现key过期了，其他线程获取到锁的问题了。

• redisson的“看门狗”逻辑保证了没有死锁发生。

  (如果机器宕机了，看门狗也就没了。此时就不会延长key的过期时间，到了30s之后就会自动过期了，其他线程可以获取到锁)

分布式锁用Redis还是 Zookeeper？

重点阅读–分布式锁用 Redis 还是 Zookeeper？

重点阅读–分布式锁用 Redis 还是 Zookeeper？

zk redis锁对cpu 硬盘 网络IO资源的消耗对比

1. redis加锁速度是zk的5-8倍左右(不同环境稍有差异)，解锁速度是zk的2~4倍左右
2. 在锁竞争状态下，zk通过watch实现监听等待，在等待期间出让cpu资源；redis通过信号量实现等待通知，在等待期间也会出让cpu资源，zk和redis在锁竞争状态下差异不大
3. zookeeper获取锁时，需要经过命令从flower到leader，leader处理并同步给flower，leader判定同步结果并commit等多个步骤，且数据持久化实时进行，因此对cpu和磁盘的性能消耗都较大，且硬盘消耗更为突出
4. redis获取锁时，数据按槽重定向后直接执行，通过lua保持所操作的原子性，且主备同步采用异步方式，牺牲了数据一致性换取时效性，因此从数据上看，redis做分布式锁效率更高，对cpu消耗大，对硬盘基本无消耗
5. 防止死锁方面，zk通过session连接超时判定client失联从而删除锁节点防止死锁，具有一定的安全性；redisson通过设置数据超时间防止client失联后的死锁发生，也具有较好的安全性
6. 性能扩展性方面，redis可以通过扩展集群节点，分散处理，降低单节点压力，从而达到提升性能的目的；zk集群由于CP导向，追求数据一致性特点，增加集群节点仅对读取性能有提升，对于写入数据(分布式锁需要写入数据)无提升，因此提升手段目前仅限于(1)提升硬件性能；(2)修改落盘配置规则(带来数据一致性风险)；(3)leader节点配置为不服务，仅处理写入操作；手段较为有限

zk优缺点

优点：CP，可靠性高；
缺点：速度相对较慢，适合数据一致性要求很高的场景，且由于写入扩展性较低，因此适合加解锁吞吐相对要求不高的场景

redis优缺点

优点：AP，速度快；
缺点：可靠性比zk低，适合数据一致性要求相对较低的场景，即分布式锁故障可收敛性在可容忍范围内时，或加解锁吞吐要求较高的场景时建议使用redis的分布式锁

Redis分布式锁问题

redis分布式锁可靠性低的原因是?

这对于单点的redis能很好地实现分布式锁，
如果redis集群，会出现master宕机的情况。如果master宕机，此时锁key还没有同步到slave节点上，会出现机器B从新的master上获取到了一个重复的锁。
设想以下执行序列：
• 机器AsetNx了一个锁key，value为当前时间加上过期时间，master更新了锁key的值；
• 此时master宕机，选举出新的master，新的master正同步数据；
• 新的master不含锁key，机器BsetNx了一个锁key，value为当前时间加上过期时间；
这样机器A和机器B都获得了一个相同的锁

分布式锁编码实现示例demo

zookeeper之Curator

Curator使用方法

org.apache.curator.framework.recipes.locks.InterProcessMutex

InterProcessMutex interProcessMutex = new InterProcessMutex(client,"/anyLock");           
interProcessMutex.acquire();           
interProcessMutex.release();

实现分布式锁的核心源码
internalLockLoop

Curator应用场景(二)-Watch监听机制

Curator应用场景(二)-Watch监听机制(NodeCache,PathChildrenCache,TreeCache)
Curator应用场景(二)-Watch监听机制

redis之Redisson

Redisson使用方法

单机模式
master-slave + sentinel选举模式
redis cluster模式

前提 redis 为cluster模式

Config config = new Config();
config.useClusterServers()
	.addNodeAddress(hostAndPorts.toArray(new String[0]))
	.setPassword(password)
	.setScanInterval(scanInterval)
	.setMasterConnectionPoolSize(masterConnectionPoolSize)
	.setSlaveConnectionPoolSize(slaveConnectionPoolSize)
	.setIdleConnectionTimeout(idleConnectionTimeout)
	.setConnectTimeout(redissonConnectTimeout)
	.setTimeout(redissonTimeout)
	.setRetryInterval(retryInterval);
redissonClient = Redisson.create(config);
RLock lock = redisson.getLock("anyLock");
lock.lock();
lock.unlock();         

源码具体实现
org.redisson.RedissonLock.tryAcquireAsync

// 加锁逻辑
private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, final long threadId) {
     if (leaseTime != -1) {
         return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
     }
     
     // 调用一段lua脚本，设置一些key、过期时间
     RFuture<Long> ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
     ttlRemainingFuture.addListener(new FutureListener<Long>() {
         @Override
         public void operationComplete(Future<Long> future) throws Exception {
             if (!future.isSuccess()) {
                 return;
             }

             Long ttlRemaining = future.getNow();
             // lock acquired
             if (ttlRemaining == null) {
      // 看门狗逻辑  
      scheduleExpirationRenewal(threadId);
             }
         }
     });
     return ttlRemainingFuture;
    }

org.redisson.RedissonLock.tryLockInnerAsync

<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    internalLockLeaseTime = unit.toMillis(leaseTime);
    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
    		    // key不存在则插入数据并设置过期时间
              "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; " +
                // key存在且为本线程创建的数据则计数加1
              "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                  "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                  "return nil; " +
              "end; " +
                // 返回锁的剩余时间 其实就是数据老化时间
              "return redis.call('pttl', KEYS[1]);",
                Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
    }

org.redisson.RedissonLock.scheduleExpirationRenewal

// 看门狗最终会调用了这里
private void scheduleExpirationRenewal(final long threadId) {
    if (expirationRenewalMap.containsKey(getEntryName())) {
         return;
     }
     // 这个任务会延迟10s执行
     Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
         @Override
         public void run(Timeout timeout) throws Exception {
             // 这个操作会将key的过期时间重新设置为30s
             RFuture<Boolean> future = renewExpirationAsync(threadId);
             
             future.addListener(new FutureListener<Boolean>() {
                 @Override
                 public void operationComplete(Future<Boolean> future) throws Exception {
                     expirationRenewalMap.remove(getEntryName());
                     if (!future.isSuccess()) {
                         log.error("Can't update lock " + getName() + " expiration", future.cause());
                         return;
                     }
                     
                     if (future.getNow()) {
                         // reschedule itself
                         // 通过递归调用本方法，无限循环延长过期时间
                         scheduleExpirationRenewal(threadId);
                     }
                 }
             });
         }
     }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);

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

RedLock算法

RedissonClient redisson = Redisson.create(config);
RLock lock1 = redisson.getFairLock("lock1");
RLock lock2 = redisson.getFairLock("lock2");
RLock lock3 = redisson.getFairLock("lock3");
RedissonRedLock multiLock = new RedissonRedLock(lock1, lock2, lock3);             
multiLock.lock();             
multiLock.unlock();