分布式锁
- 别人面试总结
- 循序渐进zookeeper
- 有部分代码redis
- Java原生的锁机制弊端
- 分布式锁原理
- zookeeper分布式锁原理
- Redis分布式锁原理
- 1 SET key value NX PX milliseconds
- 2 RedLock - Redis官方提出的一种分布式锁的算法
- 3 Redisson
- 分布式锁用Redis还是 Zookeeper？
- 重点阅读--分布式锁用 Redis 还是 Zookeeper？
- zk redis锁对cpu 硬盘 网络IO资源的消耗对比
- zk优缺点
- redis优缺点
- 分布式锁编码实现示例demo
- zookeeper之Curator
- Curator使用方法
- Curator应用场景(二)-Watch监听机制
- redis之Redisson
- Redisson使用方法
别人面试总结
循序渐进zookeeper
Zookeeper的应用-分布式锁
有部分代码redis
Java原生的锁机制弊端
某些场景在分布式部署系统的情况下，两个系统，运行在两个不同的JVM里面，他们加的锁只对属于自己JVM里面的线程有效，对于其他JVM的线程是无效的，因此Java原生的锁机制无法保证线程安全，所以我们需要用到分布式锁。
分布式锁原理
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实现分布式锁的落地方案：
- 使用zk的临时节点和有序节点，每个线程获取锁就是在zk创建一个临时有序的节点，比如在/lock/目录下。
- 创建节点成功后，获取/lock目录下的所有临时节点，再判断当前线程创建的节点是否是所有的节点的序号最小的节点
- 如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。
- 如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前一个节点添加一个事件监听。
比如当前线程获取到的节点序号为/lock/003,然后所有的节点列表为[/lock/001,/lock/002,/lock/003],则对/lock/002这个节点添加一个事件监听器。
如果锁释放了，会唤醒下一个序号的节点，然后重新执行第3步，判断是否自己的节点序号是最小。比如/lock/001释放了，/lock/002监听到时间，此时节点集合为[/lock/002,/lock/003],则/lock/002为最小序号节点，获取到锁。整个过程如下：
zk节点从一个维度分为永久节点和临时节点，从另一个维度分为无序节点和有序节点。 简单来说：
- 当zk判断client的连接timeout时，会主动删除该client的所有临时节点；
- 有序节点会按照节点创建时间生成一个序列号，该序号可以用于排序。
据此，zk使用临时有序节点来作为分布式锁的承载者：
- 利用有序的特性决定谁是锁的拥有者；
- 利用client连接断开会删除临时节点的特性来防止死锁。
- 由于节点有序，因此通过后一个节点watch前一个节点删除的监控机制实现公平锁的同时避免了惊群效应；
- 利用抢占建立临时节点并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,<key1,value>>，其中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资源的消耗对比
- redis加锁速度是zk的5-8倍左右(不同环境稍有差异)，解锁速度是zk的2~4倍左右
- 在锁竞争状态下，zk通过watch实现监听等待，在等待期间出让cpu资源；redis通过信号量实现等待通知，在等待期间也会出让cpu资源，zk和redis在锁竞争状态下差异不大
- zookeeper获取锁时，需要经过命令从flower到leader，leader处理并同步给flower，leader判定同步结果并commit等多个步骤，且数据持久化实时进行，因此对cpu和磁盘的性能消耗都较大，且硬盘消耗更为突出
- redis获取锁时，数据按槽重定向后直接执行，通过lua保持所操作的原子性，且主备同步采用异步方式，牺牲了数据一致性换取时效性，因此从数据上看，redis做分布式锁效率更高，对cpu消耗大，对硬盘基本无消耗
- 防止死锁方面，zk通过session连接超时判定client失联从而删除锁节点防止死锁，具有一定的安全性；redisson通过设置数据超时间防止client失联后的死锁发生，也具有较好的安全性
- 性能扩展性方面，redis可以通过扩展集群节点，分散处理，降低单节点压力，从而达到提升性能的目的；zk集群由于CP导向，追求数据一致性特点，增加集群节点仅对读取性能有提升，对于写入数据(分布式锁需要写入数据)无提升，因此提升手段目前仅限于(1)提升硬件性能；(2)修改落盘配置规则(带来数据一致性风险)；(3)leader节点配置为不服务，仅处理写入操作；手段较为有限
zk优缺点
优点：CP，可靠性高；
缺点：速度相对较慢，适合数据一致性要求很高的场景，且由于写入扩展性较低，因此适合加解锁吞吐相对要求不高的场景
redis优缺点
优点：AP，速度快；
缺点：可靠性比zk低，适合数据一致性要求相对较低的场景，即分布式锁故障可收敛性在可容忍范围内时，或加解锁吞吐要求较高的场景时建议使用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();
