面试题

一般实现分布式锁都有哪些方式?使用 Redis 如何设计分布式锁?使用 zk 来设计分布式锁可以吗?这两种分布式锁的实现方式哪种效率比较高?

面试官心理分析

其实一般问问题,都是这么问的,先问问你 zk,然后其实是要过渡到 zk 相关的一些问题里去,比如分布式锁。因为在分布式系统开发中,分布式锁的使用场景还是很常见的。

面试题剖析

Redis 分布式锁

官方叫做 RedLock 算法,是 Redis 官方支持的分布式锁算法。

这个分布式锁有 3 个重要的考量点:

  • 互斥(只能有一个客户端获取锁)
  • 不能死锁
  • 容错(只要大部分 Redis 节点创建了这把锁就可以)

Redis 最普通的分布式锁

第一个最普通的实现方式,就是在 Redis 里使用 SET key value [EX seconds] [PX milliseconds] NX 创建一个 key,这样就算加锁。其中:

  • NX:表示只有 key 不存在的时候才会设置成功,如果此时 redis 中存在这个 key,那么设置失败,返回 nil
  • EX seconds:设置 key 的过期时间,精确到秒级。意思是 seconds 秒后锁自动释放,别人创建的时候如果发现已经有了就不能加锁了。
  • PX milliseconds:同样是设置 key 的过期时间,精确到毫秒级。

比如执行以下命令:

  1. SET resource_name my_random_value PX 30000 NX

释放锁就是删除 key ,但是一般可以用 lua 脚本删除,判断 value 一样才删除:

  1. -- 删除锁的时候,找到 key 对应的 value,跟自己传过去的 value 做比较,如果是一样的才删除。
  2. if redis.call("get",KEYS[1]) == ARGV[1] then
  3. return redis.call("del",KEYS[1])
  4. else
  5. return 0
  6. end

为啥要用 random_value 随机值呢?因为如果某个客户端获取到了锁,但是阻塞了很长时间才执行完,比如说超过了 30s,此时可能已经自动释放锁了,此时可能别的客户端已经获取到了这个锁,要是你这个时候直接删除 key 的话会有问题,所以得用随机值加上面的 lua 脚本来释放锁。

但是这样是肯定不行的。因为如果是普通的 Redis 单实例,那就是单点故障。或者是 Redis 普通主从,那 Redis 主从异步复制,如果主节点挂了(key 就没有了),key 还没同步到从节点,此时从节点切换为主节点,别人就可以 set key,从而拿到锁。

RedLock 算法

这个场景是假设有一个 Redis cluster,有 5 个 Redis master 实例。然后执行如下步骤获取一把锁:

  1. 获取当前时间戳,单位是毫秒;
  2. 跟上面类似,轮流尝试在每个 master 节点上创建锁,超时时间较短,一般就几十毫秒(客户端为了获取锁而使用的超时时间比自动释放锁的总时间要小。例如,如果自动释放时间是 10 秒,那么超时时间可能在 5~50 毫秒范围内);
  3. 尝试在大多数节点上建立一个锁,比如 5 个节点就要求是 3 个节点 n / 2 + 1
  4. 客户端计算建立好锁的时间,如果建立锁的时间小于超时时间,就算建立成功了;
  5. 要是锁建立失败了,那么就依次之前建立过的锁删除;
  6. 只要别人建立了一把分布式锁,你就得不断轮询去尝试获取锁

redis-redlock

Redis 官方给出了以上两种基于 Redis 实现分布式锁的方法,详细说明可以查看:https://redis.io/topics/distlock

zk 分布式锁

zk 分布式锁,其实可以做的比较简单,就是某个节点尝试创建临时 znode,此时创建成功了就获取了这个锁;这个时候别的客户端来创建锁会失败,只能注册个监听器监听这个锁。释放锁就是删除这个 znode,一旦释放掉就会通知客户端,然后有一个等待着的客户端就可以再次重新加锁。

  1. /**
  2. * ZooKeeperSession
  3. */
  4. public class ZooKeeperSession {
  5. private static CountDownLatch connectedSemaphore = new CountDownLatch(1);
  6. private ZooKeeper zookeeper;
  7. private CountDownLatch latch;
  8. public ZooKeeperSession() {
  9. try {
  10. this.zookeeper = new ZooKeeper("192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181", 50000, new ZooKeeperWatcher());
  11. try {
  12. connectedSemaphore.await();
  13. } catch (InterruptedException e) {
  14. e.printStackTrace();
  15. }
  16. System.out.println("ZooKeeper session established......");
  17. } catch (Exception e) {
  18. e.printStackTrace();
  19. }
  20. }
  21. /**
  22. * 获取分布式锁
  23. *
  24. * @param productId
  25. */
  26. public Boolean acquireDistributedLock(Long productId) {
  27. String path = "/product-lock-" + productId;
  28. try {
  29. zookeeper.create(path, "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
  30. return true;
  31. } catch (Exception e) {
  32. while (true) {
  33. try {
  34. // 相当于是给node注册一个监听器,去看看这个监听器是否存在
  35. Stat stat = zk.exists(path, true);
  36. if (stat != null) {
  37. this.latch = new CountDownLatch(1);
  38. this.latch.await(waitTime, TimeUnit.MILLISECONDS);
  39. this.latch = null;
  40. }
  41. zookeeper.create(path, "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
  42. return true;
  43. } catch (Exception ee) {
  44. continue;
  45. }
  46. }
  47. }
  48. return true;
  49. }
  50. /**
  51. * 释放掉一个分布式锁
  52. *
  53. * @param productId
  54. */
  55. public void releaseDistributedLock(Long productId) {
  56. String path = "/product-lock-" + productId;
  57. try {
  58. zookeeper.delete(path, -1);
  59. System.out.println("release the lock for product[id=" + productId + "]......");
  60. } catch (Exception e) {
  61. e.printStackTrace();
  62. }
  63. }
  64. /**
  65. * 建立 zk session 的 watcher
  66. */
  67. private class ZooKeeperWatcher implements Watcher {
  68. public void process(WatchedEvent event) {
  69. System.out.println("Receive watched event: " + event.getState());
  70. if (KeeperState.SyncConnected == event.getState()) {
  71. connectedSemaphore.countDown();
  72. }
  73. if (this.latch != null) {
  74. this.latch.countDown();
  75. }
  76. }
  77. }
  78. /**
  79. * 封装单例的静态内部类
  80. */
  81. private static class Singleton {
  82. private static ZooKeeperSession instance;
  83. static {
  84. instance = new ZooKeeperSession();
  85. }
  86. public static ZooKeeperSession getInstance() {
  87. return instance;
  88. }
  89. }
  90. /**
  91. * 获取单例
  92. *
  93. * @return
  94. */
  95. public static ZooKeeperSession getInstance() {
  96. return Singleton.getInstance();
  97. }
  98. /**
  99. * 初始化单例的便捷方法
  100. */
  101. public static void init() {
  102. getInstance();
  103. }
  104. }

也可以采用另一种方式,创建临时顺序节点:

如果有一把锁,被多个人给竞争,此时多个人会排队,第一个拿到锁的人会执行,然后释放锁;后面的每个人都会去监听排在自己前面的那个人创建的 node 上,一旦某个人释放了锁,排在自己后面的人就会被 ZooKeeper 给通知,一旦被通知了之后,就 ok 了,自己就获取到了锁,就可以执行代码了。

  1. public class ZooKeeperDistributedLock implements Watcher {
  2. private ZooKeeper zk;
  3. private String locksRoot = "/locks";
  4. private String productId;
  5. private String waitNode;
  6. private String lockNode;
  7. private CountDownLatch latch;
  8. private CountDownLatch connectedLatch = new CountDownLatch(1);
  9. private int sessionTimeout = 30000;
  10. public ZooKeeperDistributedLock(String productId) {
  11. this.productId = productId;
  12. try {
  13. String address = "192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181";
  14. zk = new ZooKeeper(address, sessionTimeout, this);
  15. connectedLatch.await();
  16. } catch (IOException e) {
  17. throw new LockException(e);
  18. } catch (KeeperException e) {
  19. throw new LockException(e);
  20. } catch (InterruptedException e) {
  21. throw new LockException(e);
  22. }
  23. }
  24. public void process(WatchedEvent event) {
  25. if (event.getState() == KeeperState.SyncConnected) {
  26. connectedLatch.countDown();
  27. return;
  28. }
  29. if (this.latch != null) {
  30. this.latch.countDown();
  31. }
  32. }
  33. public void acquireDistributedLock() {
  34. try {
  35. if (this.tryLock()) {
  36. return;
  37. } else {
  38. waitForLock(waitNode, sessionTimeout);
  39. }
  40. } catch (KeeperException e) {
  41. throw new LockException(e);
  42. } catch (InterruptedException e) {
  43. throw new LockException(e);
  44. }
  45. }
  46. public boolean tryLock() {
  47. try {
  48. // 传入进去的locksRoot + “/” + productId
  49. // 假设productId代表了一个商品id,比如说1
  50. // locksRoot = locks
  51. // /locks/10000000000,/locks/10000000001,/locks/10000000002
  52. lockNode = zk.create(locksRoot + "/" + productId, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
  53. // 看看刚创建的节点是不是最小的节点
  54. // locks:10000000000,10000000001,10000000002
  55. List<String> locks = zk.getChildren(locksRoot, false);
  56. Collections.sort(locks);
  57. if(lockNode.equals(locksRoot+"/"+ locks.get(0))){
  58. //如果是最小的节点,则表示取得锁
  59. return true;
  60. }
  61. //如果不是最小的节点,找到比自己小1的节点
  62. int previousLockIndex = -1;
  63. for(int i = 0; i < locks.size(); i++) {
  64. if(lockNode.equals(locksRoot + “/” + locks.get(i))) {
  65. previousLockIndex = i - 1;
  66. break;
  67. }
  68. }
  69. this.waitNode = locks.get(previousLockIndex);
  70. } catch (KeeperException e) {
  71. throw new LockException(e);
  72. } catch (InterruptedException e) {
  73. throw new LockException(e);
  74. }
  75. return false;
  76. }
  77. private boolean waitForLock(String waitNode, long waitTime) throws InterruptedException, KeeperException {
  78. Stat stat = zk.exists(locksRoot + "/" + waitNode, true);
  79. if (stat != null) {
  80. this.latch = new CountDownLatch(1);
  81. this.latch.await(waitTime, TimeUnit.MILLISECONDS);
  82. this.latch = null;
  83. }
  84. return true;
  85. }
  86. public void unlock() {
  87. try {
  88. // 删除/locks/10000000000节点
  89. // 删除/locks/10000000001节点
  90. System.out.println("unlock " + lockNode);
  91. zk.delete(lockNode, -1);
  92. lockNode = null;
  93. zk.close();
  94. } catch (InterruptedException e) {
  95. e.printStackTrace();
  96. } catch (KeeperException e) {
  97. e.printStackTrace();
  98. }
  99. }
  100. public class LockException extends RuntimeException {
  101. private static final long serialVersionUID = 1L;
  102. public LockException(String e) {
  103. super(e);
  104. }
  105. public LockException(Exception e) {
  106. super(e);
  107. }
  108. }
  109. }

但是,使用 zk 临时节点会存在另一个问题:由于 zk 依靠 session 定期的心跳来维持客户端,如果客户端进入长时间的 GC,可能会导致 zk 认为客户端宕机而释放锁,让其他的客户端获取锁,但是客户端在 GC 恢复后,会认为自己还持有锁,从而可能出现多个客户端同时获取到锁的情形。#209

针对这种情况,可以通过 JVM 调优,尽量避免长时间 GC 的情况发生。

redis 分布式锁和 zk 分布式锁的对比

  • redis 分布式锁,其实需要自己不断去尝试获取锁,比较消耗性能。
  • zk 分布式锁,获取不到锁,注册个监听器即可,不需要不断主动尝试获取锁,性能开销较小。

另外一点就是,如果是 Redis 获取锁的那个客户端 出现 bug 挂了,那么只能等待超时时间之后才能释放锁;而 zk 的话,因为创建的是临时 znode,只要客户端挂了,znode 就没了,此时就自动释放锁。

Redis 分布式锁大家没发现好麻烦吗?遍历上锁,计算时间等等……zk 的分布式锁语义清晰实现简单。

所以先不分析太多的东西,就说这两点,我个人实践认为 zk 的分布式锁比 Redis 的分布式锁牢靠、而且模型简单易用。