分布式锁—1.原理算法和使用建议二
大纲
1.Redis分布式锁的8大问题
2.Redis的RedLock算法分析
3.基于Redis和zk的分布式锁实现原理
4.Redis分布式锁的问题以及使用建议
3.Redis和zk的分布式锁实现原理对比
(1)Redis分布式锁的简单实现
(2)Redis官方的RedLock算法
(3)zk分布式锁之排他锁实现原理
(4)zk分布式锁之读写锁实现原理
(5)zk分布式锁的一个简单实现
(6)Redis分布式锁和zk分布式锁的对比
问题汇总：
一般实现分布式锁都有哪些方式？使用Redis如何设计分布式锁，使用zk来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？
(1)Redis分布式锁的简单实现
Redis分布式锁使用RedLock算法，是Redis官方支持的分布式锁算法，这个分布式锁有3个考量点：
考量点一：互斥，只能有一个客户端获取锁
考量点二：不能产生死锁
考量点三：容错，允许其中的节点出现故障而不影响分布式锁功能
一.获取锁
最普通的实现方式就是在Redis里创建一个key。如果创建成功，那么就认为获取锁成功。如果创建失败，即发现已经有该key了，则说明获取锁失败。
通常使用如下这样的命令进行创建：
/** 说明一："my:lock"就是锁的名称，对应于Redis的key */
/** 说明二：Redis中这个名为"my:lock"的key对应的值必须是一个随机值 */
/** 说明三：NX的意思是只有key不存在的时候才会设置成功 */
/** 说明四："PX 30000"的意思是30秒后锁自动释放 */
SET my:lock 随机值 NX PX 30000二.释放锁
释放锁就是删除key，但是一般用lua脚本进行删除，并且是判断随机value一样才进行删除。
//删除key的lua脚本
String script =
"if redis.call('get', KEYS[1]) == ARGV[1] then" +
"return redis.call('del', KEYS[1]);" +
"else" +
"return 0;" +
"end;";为什么必须要用随机值：
因为如果某个客户端获取到了锁，但阻塞了很长时间才执行完。此时可能由于过期时间已到而自动释放了锁，而别的客户端又刚好获取到锁，这个时候如果该客户端直接删除key那么就会有问题。所以才必须先对key设置随机值，然后再按key + 随机值来删除key释放锁。
三.这套Redis获取锁 + 释放锁的方案存在的问题
问题一：单点故障。如果Redis服务是普通的单实例，那么就会有单点故障的风险。
问题二：破坏互斥。如果Redis服务是普通主从架构，Redis进行的是主从异步复制。那么当Redis主节点挂了，key还没同步到从节点时，一旦从节点切换为主节点，其他系统的线程就会拿到锁。
(2)Redis官方的RedLock算法
RedLock算法主要是通过过半机制来避免单节点故障导致的锁没同步问题，RedLock算法在获取锁 + 释放锁的方案上基本和前面一致。但实际上这种RedLock算法也有很多问题，不是很完美。
RedLock算法获取一把锁的步骤：
步骤一：客户端先获取当前时间戳T1。
步骤二：客户端依次向这5个节点发起加锁请求，且每个请求都会设置超时时间，也是使用"SET my:lock 随机值 NX PX 50"创建锁。超时时间是毫秒级的，要远小于锁的有效时间，而且一般是几十毫秒。如果某一个节点加锁失败，包括网络超时、锁被其它线程持有等各种情况，那么就立即向下一个Redis节点申请加锁。
步骤三：如果客户端从3个以上(过半)节点加锁成功，则再次获取当前时间戳T2。如果T2 - T1 < 锁的过期时间，则认为客户端加锁成功，否则加锁失败。
步骤四：如果加锁失败，要向全部节点发起释放锁的请求。如果加锁成功，则去操作共享资源，也是使用lua按照key + 随机值进行删除。
(3)zk分布式锁之排他锁的实现原理
一.获取锁
使用临时顺序节点来表示获取锁的请求，让创建出后缀数字最小的节点的客户端成功拿到锁。
步骤一：客户端调用create()方法在"/exclusive_lock"节点下创建临时顺序节点。
步骤二：然后调用getChildren()方法返回"/exclusive_lock"下的所有子节点，接着对这些子节点进行排序。
步骤三：排序后，看看是否有后缀比自己小的节点。如果没有，则当前客户端便成功获取到排他锁。如果有，则调用exist()方法对排在自己前面的那个节点注册Watcher监听。
步骤四：当客户端收到Watcher通知前面的节点不存在，则重复步骤二。
二.释放锁
如果获取锁的客户端宕机，那么客户端在zk上对应的临时节点就会被移除。如果获取锁的客户端执行完，会主动将自己创建的临时节点删除。
(4)zk分布式锁之读写锁的实现原理
一.获取锁
步骤一：客户端调用create()方法在"/shared_lock"节点下创建临时顺序节点。如果是读请求，那么就创建"/shared_lock/read001"的临时顺序节点。如果是写请求，那么就创建"/shared_lock/write002"的临时顺序节点。
步骤二：然后调用getChildren()方法返回"/shared_lock"下的所有子节点，接着对这些子节点进行排序。
步骤三：对于读请求：如果排序后发现有比自己序号小的写请求子节点，则需要等待，且需要向比自己序号小的最后一个写请求子节点注册Watcher监听。
对于写请求：如果排序后发现自己不是序号最小的请求子节点，则需要等待，并且需要向比自己序号小的最后一个请求子节点注册Watcher监听。
注意：这里注册Watcher监听也是调用exist()方法。此外，不满足上述条件则表示成功获取共享锁。
步骤四：如果客户端在等待过程中接收到Watcher通知，则重复步骤二。
二.释放锁
如果获取锁的客户端宕机，那么zk上的对应的临时顺序节点就会被移除。如果获取锁的客户端执行完，会主动将自己创建的临时顺序节点删除。
(5)zk分布式锁的一个简单实现
一.分布式锁的实现步骤
步骤一：每个线程都通过"临时顺序节点 + zk.create()方法 + 添加回调"去创建节点。
步骤二：线程执行完创建临时顺序节点后，先通过CountDownLatch.await()方法进行阻塞。然后在创建成功的回调中，通过zk.getChildren()方法获取根目录并继续回调。
步骤三：某线程在获取根目录成功后的回调中，会对目录排序。排序后如果发现其创建的节点排第一，那么就执行countDown()方法表示获取锁成功。排序后如果发现其创建的节点不是第一，那么就通过zk.exists()方法监听前一节点。
步骤四：获取到锁的线程会通过zk.delete()方法来删除其对应的节点实现释放锁，在等候获取锁的线程掉线时其对应的节点也会被删除。而一旦节点被删除，那些监听根目录的线程就会重新执行zk.getChildren()方法，获取成功后其回调又会进行排序以及通过zk.exists()方法监听前一节点。
二.WatchCallBack对分布式锁的具体实现
public class WatchCallBack implements Watcher, AsyncCallback.StringCallback, AsyncCallback.Children2Callback, AsyncCallback.StatCallback {
ZooKeeper zk ;
String threadName;
CountDownLatch countDownLatch = new CountDownLatch(1);
String pathName;
public String getPathName() {
return pathName;
}
public void setPathName(String pathName) {
this.pathName = pathName;
}
public String getThreadName() {
return threadName;
}
public void setThreadName(String threadName) {
this.threadName = threadName;
}
public ZooKeeper getZk() {
return zk;
}
public void setZk(ZooKeeper zk) {
this.zk = zk;
}
public void tryLock() {
try {
System.out.println(threadName + " create....");
//创建一个临时的有序的节点
zk.create("/lock", threadName.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL, this, "abc");
countDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
//当前线程释放锁, 删除节点
public void unLock() {
try {
zk.delete(pathName, -1);
System.out.println(threadName + " over work....");
} catch (InterruptedException e) {
e.printStackTrace();
} catch (KeeperException e) {
e.printStackTrace();
}
}
//上面zk.create()方法的回调
//创建临时顺序节点后的回调, 10个线程都能同时创建节点
//创建完后获取根目录下的子节点, 也就是这10个线程创建的节点列表, 这个不用watch了, 但获取成功后要执行回调
//这个回调就是每个线程用来执行节点排序, 看谁是第一就认为谁获得了锁
@Override
public void processResult(int rc, String path, Object ctx, String name) {
if (name != null ) {
System.out.println(threadName + " create node : " + name );
setPathName(name);
//一定能看到自己前边的, 所以这里的watch要是false
zk.getChildren("/", false, this ,"sdf");
}
}
//核心方法: 各个线程获取根目录下的节点时, 上面zk.getChildren("/", false, this ,"sdf")的回调
@Override
public void processResult(int rc, String path, Object ctx, List<String> children, Stat stat) {
//一定能看到自己前边的节点
System.out.println(threadName + "look locks...");
for (String child : children) {
System.out.println(child);
}
//根目录下的节点排序
Collections.sort(children);
//获取当前线程创建的节点在根目录中排第几
int i = children.indexOf(pathName.substring(1));
//是不是第一个, 如果是则说明抢锁成功; 如果不是, 则watch当前线程创建节点的前一个节点是否被删除(删除);
if (i == 0) {
System.out.println(threadName + " i am first...");
try {
//这里的作用就是不让第一个线程获得锁释放锁跑得太快, 导致后面的线程还没建立完监听第一个节点就被删了
zk.setData("/", threadName.getBytes(), -1);
countDownLatch.countDown();
} catch (KeeperException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
} else {
//9个没有获取到锁的线程都去调用zk.exists, 去监控各自自己前面的节点, 而没有去监听父节点
//如果各自前面的节点发生删除事件的时候才回调自己, 并关注被删除的事件(所以会执行process回调)
zk.exists("/" + children.get(i-1), this, this, "sdf");
}
}
//上面zk.exists()的监听
//监听的节点发生变化的Watcher事件监听
@Override
public void process(WatchedEvent event) {
//如果第一个获得锁的线程释放锁了, 那么其实只有第二个线程会收到回调事件
//如果不是第一个哥们某一个挂了, 也能造成他后边的收到这个通知, 从而让他后边那个去watch挂掉这个哥们前边的, 保持顺序
switch (event.getType()) {
case None:
break;
case NodeCreated:
break;
case NodeDeleted:
zk.getChildren("/", false, this ,"sdf");
break;
case NodeDataChanged:
break;
case NodeChildrenChanged:
break;
}
}
@Override
public void processResult(int rc, String path, Object ctx, Stat stat) {
//TODO
}
}三.分布式锁的测试类
package com.demo.zookeeper.lock;
import com.demo.zookeeper.config.ZKUtils;
import org.apache.zookeeper.ZooKeeper;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
public class TestLock {
ZooKeeper zk;
@Before
public void conn() {
zk = ZKUtils.getZK();
}
@After
public void close() {
try {
zk.close();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
@Test
public void lock() {
//10个线程都去抢锁
for (int i = 0; i < 10; i++) {
new Thread() {
@Override
public void run() {
WatchCallBack watchCallBack = new WatchCallBack();
watchCallBack.setZk(zk);
String threadName = Thread.currentThread().getName();
watchCallBack.setThreadName(threadName);
//每一个线程去抢锁
watchCallBack.tryLock();
//抢到锁之后才能干活
System.out.println(threadName + " working...");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
//干完活释放锁
watchCallBack.unLock();
}
}.start();
}
while(true) {
}
}
}(6)Redis分布式锁和zk分布式锁的对比
一.性能开销方面
对于Redis分布式锁，客户端需要不断去尝试获取锁，比较消耗性能。对于zk分布式锁，当客户端获取不到锁时，只需要注册一个监听器即可。所以zk分布式锁不需要不断主动地尝试获取锁，性能开销小。
二.异常释放锁方面
对于Redis分布式锁，如果获取到锁的客户端挂了，那么只能等过期时间后才能释放锁。对于zk分布式锁，获取锁时创建的是临时节点，即便客户端挂了，由于临时节点会被zk删除，所以会自动释放锁。
三.实现方面
Redis分布式锁的RedLock算法比较麻烦，需要遍历上锁、计算时间等。而zk的分布式锁语义清晰实现简单，zk的分布式锁比Redis的分布式锁牢靠、而且模型简单易用。
四.性能方面
Redis和zk都是基于内存去通过写数据来创建锁的，但是因为zk有过半写机制，所以Redis能够承受更高的QPS。
五.支持方面
Redisson可以对分布式锁提供非常好的支持，zk的Curator则没有这么好的支持。
4.Redis分布式锁的问题以及使用建议
(1)Redis分布式锁的问题
(2)Redis分布式锁的优点
(3)zk分布式锁
(4)使用建议
(5)一点思考
(1)Redis分布式锁的问题
第一种方案：基于Redis单实例 + setnx随机值 + lua删除key
如果出现Redis单点故障，会导致系统全盘崩溃，做不到高可用。除非是那种不太核心的小系统，随便用一下分布式锁，那么可以使用Redis单实例。
第二种方案：基于Redis主从架构 + 哨兵 + setnx随机值 + lua删除key
Redis主从+哨兵保证了高可用，Master宕机，Slave会接替。但是存在隐患，即在Master宕机的瞬间：如果刚创建的锁还没异步复制到Slave，那么就会导致重复加锁的问题。虽然主从 + 哨兵保证了高可用，但锁的实现有漏洞，可能会导致系统异常。
第三种方案：使用RedLock算法
通过twemproxy、Codis、Redis Cluster可以实现Redis集群分片。面对Redis的多Master集群，此时使用的是RedLock算法，但不推荐，因为实现过程太复杂繁琐、很脆弱。因网络原因，难以实现多节点同时设置分布式锁，锁失效时间都会不一样。不同Linux机器的时间不同步 + 各种无法考虑到的问题，可能导致重复加锁。
举个例子：客户端A给5个Redis Master都设置了一个key上了一把锁，失效时间是10s。因为网络等各种情况不同，各个Master对key的过期处理可能不同步。可能会出现：客户端A由于某些原因处理耗时特别长所以还没释放锁，然后过了大概10秒，其中3台机器的key都到期失效了。此时客户端A还没释放锁，而客户端B却发起设置请求，刚好成功加到锁。于是出现两个客户端同时持有锁。
RedLock算法存在两个问题：
问题一：实现过程和步骤太复杂，上锁的过程和机制很重很复杂，导致很脆弱，各种意想不到的情况都可能发生。
问题二：网络原因和各服务器的时钟问题导致对key的过期处理并不同步，不够健壮，不一定能完全实现健壮的分布式锁的语义。
RedLock算法的问题总结：
第一是太复杂
第二是不健壮可能重复加锁
Redis分布式锁总结：
Redis分布式锁实际上没有100%完美的方案，或多或少有点问题。实际生产系统中，有时候用zk分布式锁，有时候也会用Redis分布式锁。
(2)Redis分布式锁的优点
Redis分布式锁有一个优点，就是拥有优秀的Redis客户端类库Redisson。Redisson封装了大量基于Redis的复杂操作，比如数据集合(Map、Set、List)的分布式的存储、各种复杂的分布式锁等。甚至基于Redis+Redisson，就可以将Redis作为一个轻量级的NoSQL使用。
Redisson对Redis分布式锁的支持非常友好，比如支持可重入锁、读写锁、公平锁、信号量、CountDownLatch等。Redisson支持很多种复杂的锁的语义，提供了各种分布式锁的高级支持，Redisson这个客户端框架本身就有完整的一套Redis分布式锁实现。
(3)zk分布式锁
zk分布式锁的优点是锁模型健壮、稳定、简单、可用性高，zk分布式锁的缺点是性能不如Redis，而且部署和运维成本高。
Curator客户端主要还是针对zk的一些基础语义进行封装。Curator之于zk，就类似于Jedis之于Redis。Curator也封装了多种不同的锁类型，比如可重入锁、读写锁、公平锁、信号量、CountDownLatch等锁类型。
Redis的Jedis可以和Redisson结合起来一起使用，因为Jedis封装了Redis的一些基础语义和操作。
(4)使用建议
目前行业里，基本都会有使用Redis或zk做分布式锁。Redis分布式锁没有100%完美和健壮的锁模型，或多或少会导致一些问题。如果业务场景能容忍这些问题，同时需要Redission的复杂的锁类型支持，那么可以使用Redis分布式锁。
zk分布式锁有完美健壮的锁模型，但没有太好的开源类库支持复杂锁类型。如果业务场景要求锁的语义健壮稳定，不能出现多客户端同时加到一把锁，且对锁的功能没有特别需求，那么可以使用zk分布式锁。
(5)一点思考
设计架构为什么偏好用zk分布式锁，原因两个：
原因一是Redis分布式锁的算法模型有隐患，zk分布式锁的机制更加健壮稳定。
原因二是Redis的本质是分布式缓存，zk的本质是分布式协调服务。
此外，如下是一些关于Redis框架的发展看法：
Redis现在越来越往队列、分布式锁、发布订阅等功能发展，有点本末倒置。Redis框架应该回归它的本质去发展，它的本质是一个kv缓存。Redis框架如果要发展，应该是纵向发展。比如支持磁盘存储、可以支持磁盘 + 内存的大规模海量数据的kv存储，而且Redis作为开源项目，最好提供一些便于集群管理和运维操作的功能。
比如提供便捷的可视化界面实现如下等功能来支持使用方高效管理：一键部署集群、集群上下线节点、集群数据迁移、集群数据备份、不同集群模式的一键转换(单实例模式->主从模式->哨兵模式->集群模式)、一键集群版本滚动升级、子集群模式与业务隔离、热key大value的自动发现与报警、集群资源的监控与报警、多机房集群部署容灾、集群访问量监控与扩容预警等。这些功能虽然Cache Clound有提供，但各大公司都要自己重复造轮子。
让人失望的是：Redis Cluster刚出来时还不支持读写分离，其Slave只做高可用自动切换。而且运维极其繁琐，还有RedLock分布式锁算法本身也不健壮。此外还支持队列、支持发布订阅等。Redis天然就不是为了分布式锁这种分布式系统的基础组件来设计的。zk才是最适合做各种分布式系统的基础设施依赖的，而且业界基本各大开源项目，都依赖zk做各种分布式系统的基础设施。