22.分布式锁常见问题总结

参考
分布式锁 & 面试题

2.2 Zookeeper分布式锁的基本原理

假设有两个服务A、B希望获得同一把锁，执行过程大致如下:

Step1： 服务A向zookeeper申请获得锁，该请求将尝试在zookeeper内创建一个临时节点(ephemeral znode)，如果没有同名的临时节点存在，则znode创建成功，标志着服务A成功的获得了锁。

Step2： 服务B向zookeeper申请获得锁，同样尝试在zookeeper内创建一个临时节点(名称必须与服务A的相同)，由于同名znode已经存在，因此请求被拒绝。接着，服务B会在zk中注册一个监听器，用于监听临时节点被删除的事件。

Step3： 若服务A主动向zk发起请求释放锁，或者服务A宕机、断开与zk的网络连接，zk会将服务A(创建者)创建的临时节点删除。而删除事件也将立刻被监听器捕获到，并反馈给服务B。最后，服务B再次向zookeeper申请获得锁。

2.1 在Redis内创建一个key来充当锁

假设有两个服务A、B都希望获得锁，执行过程大致如下:

Step1： 服务A为了获得锁，向Redis发起如下命令: SET productId:lock 0xx9p03001 NX PX 30000 其中，"productId"由自己定义，可以是与本次业务有关的id，"0xx9p03001"是一串随机值，必须保证全局唯一(原因在后文中会提到)，“NX"指的是当且仅当key(也就是案例中的"productId:lock”)在Redis中不存在时，返回执行成功，否则执行失败。"PX 30000"指的是在30秒后，key将被自动删除。执行命令后返回成功，表明服务成功的获得了锁。

Step2: 服务B为了获得锁，向Redis发起同样的命令: SET productId:lock 0000111 NX PX 30000
由于Redis内已经存在同名key，且并未过期，因此命令执行失败，服务B未能获得锁。服务B进入循环请求状态，比如每隔1秒钟(自行设置)向Redis发送请求，直到执行成功并获得锁。

Step3: 服务A的业务代码执行时长超过了30秒，导致key超时，因此Redis自动删除了key。此时服务B再次发送命令执行成功，假设本次请求中设置的value值为0000222。

Step4: 服务A执行完毕，为了释放锁，服务A会主动向Redis发起删除key的请求。注意: 在删除key之前，一定要判断服务A持有的value与Redis内存储的value是否一致。比如当前场景下，Redis中的锁早就不是服务A持有的那一把了，而是由服务2创建，如果贸然使用服务A持有的key来删除锁，则会误将服务2的锁释放掉;

三. 各项分布锁的比较

借助Redis实现分布式锁时，有一个共同的缺陷: 当获取锁被决绝后，需要不断的循环，重新发送获取锁(创建key)的请求，直到请求成功。这就造成空转，浪费宝贵的CPU资源。

RedLock算法本身有争议，并不能保证健壮性。

Redisson实现分布式锁时，除了将key新增到某个指定的master节点外，还需要由master自动异步的将key和value等数据同步至绑定的slave节点上。那么问题来了，如果master没来得及同步数据，突然发生宕机，那么通过故障转移和主备切换，slave节点被迅速升级为master节点，新的客户端加锁成功，旧的客户端的watch dog发现key存在，误以为旧客户端仍然持有这把锁，这就导致同时存在多个客户端持有同名锁的问题了。

反观Zookeeper，它在实现分布式锁时，通过在ZK上注册监听器,不需要不断的主动尝试获取锁,因此性能开销小。

数据库作为分布式数据库锁

数据库分布式锁,性能不高,实现起来会稍微复杂;还是单点,自动解锁机制需要手动实现;非阻塞,没有监听锁状态机制;非重入,同一个线程访问时无法获取到锁等等问题;虽然可以手动实现,但是会造成使用数据库锁的难度;
解决方案：
1、数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。
2、没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
3、非阻塞的？搞一个while循环，直到insert成功再返回成功。
4、非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。