浅谈分布式锁

一、分布式锁要解决的问题

分布式锁是一个在分布式环境中的重要原语，它表明不同进程间采用互斥的方式操作共享资源。常见的场景是作为一个sdk被引入到大型项目中，主要解决两类问题：

提升效率：

• 加锁是为了避免不必要的重复处理。例如防止幂等任务被多个执行者抢占。此时对锁的正确性要求不高；

保证正确性：

• 加锁是为了避免Race Condition导致逻辑错误。例如直接使用分布式锁实现防重，幂等机制。此时如果锁出现错误会引起严重后果，因此对锁的正确性要求高。

二、什么场景下需要使用分布式锁？

• 系统是一个分布式系统，java的锁已经锁不住了。
• 操作共享资源，比如库里唯一的用户数据。
• 同步访问，即多个进程同时操作共享资源。

举个栗子：「消费积分」

• 消费积分在很多系统里都有，信用卡，电商网站等等通过积分换礼品等，这里“「消费积分」”这个操作典型的需要使用锁的场景。

• 以积分兑换礼品为例来讲，完整的积分消费过程简单分成3步：
  A1：用户选中商品，发起兑换提交订单。
  A2：系统读取用户剩余积分：判断用户当前积分是否充足。
  A3：扣掉用户积分。

• 系统给用户发放积分也简单分成3步：
  B1：计算用户当天应得积分
  B2：读取用户原有积分
  B3：在原有积分上增加本次应得积分

• 那么问题来了，如果用户消费积分和用户累加积分同时发生（同时用户积分进行操作）会怎样？

  1、用户U有1000积分（记录用户积分的数据可以理解为「共享资源」），本次兑换要消耗掉999积分。

  • 不加锁的情况：
    事件A程序在执行到第2步读积分时，A:2操作读到的结果是1000分，判断剩余积分够本次兑换，紧接着要执行第3步A:3操作扣积分（1000 - 999 = 1），正常结果应该是用户还是1分。
    但是这个时候事件B也在执行，本次要给用户U发放100积分，两个线程同时进行同步访问，不加锁的情况，就会有下面这种可能，A:2 -> B:2 -> A:3 -> B:3 ,在A:3尚未完成前（扣积分，1000 - 999），用户U总积分被事件B的线程读取了，
    最后用户U的总积分变成了1100分，还白白兑换了一个999积分的礼物，这显然不符合预期结果。
  • 有人说怎么可能这么巧同时操作用户积分，cpu那么快，只要用户足够多，并发量足够大，墨菲定律迟早生效，出现上述bug只是时间问题，还有可能被黑产行业卡住这个bug疯狂薅羊毛，这个时候作为开发人员要解决这个隐患就必须了解锁的使用。

• Java本身提供了两种内置的锁的实现，一种是由JVM实现的synchronized 和 JDK 提供的 Lock，以及很多原子操作类都是线程安全的，当你的应用是单机或者说单进程应用时，可以使用这两种锁来实现锁。

• 但是当下互联网公司的系统几乎都是分布式的，这个时候Java自带的 synchronized 或 Lock 已经无法满足分布式环境下锁的要求了，因为代码会部署在多台机器上，为了解决这个问题，分布式锁应运而生，分布式锁的特点是多进程，多个物理机器上无法共享内存，常见的解决办法是基于内存层的干涉，落地方案就是基于Redis的分布式锁 or ZooKeeper分布式锁。

三、常见的三种分布式锁有哪些解决方案

3.1 基于Redis的分布式锁，Reids的分布式锁，很多大公司会基于Reidis做扩展开发。

方法一：使用setnx命令加锁

public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {
  // 第一步：加锁
    Long result = jedis.setnx(lockKey, requestId);
    if (result == 1) {
        // 第二步：设置过期时间
        jedis.expire(lockKey, expireTime);
    }
}

• 代码解释：
  • setnx命令，意思就是 set if not exist，如果lockKey不存在，把key存入Redis，保存成功后如果result返回1，表示设置成功，如果非1，表示失败，别的线程已经设置过了。
  • expire()，设置过期时间，防止死锁，假设，如果一个锁set后，一直不删掉，那这个锁相当于一直存在，产生死锁。
  • 加锁总共分两步，第一步jedis.setnx，第二步jedis.expire设置过期时间，setnx与expire不是一个原子操作，如果程序执行完第一步后异常了，第二步jedis.expire(lockKey, expireTime)没有得到执行，相当于这个锁没有过期时间，有产生死锁的可能。正对这个问题如何改进？
• 代码改进：

public class RedisLockDemo {

    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean getLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

    // 两步合二为一，一行代码加锁并设置 + 过期时间。
        if (1 == jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime)) {
            return true;//加锁成功
        }
        return false;//加锁失败
    }
}

• 代码解释：
  • 将加锁和设置过期时间合二为一，一行代码搞定，原子操作。

使用del命令解锁

释放锁就是删除key

public static void unLock(Jedis jedis, String lockKey, String requestId) {     
    // 第一步： 使用 requestId 判断加锁与解锁是不是同一个客户端
    if (requestId.equals(jedis.get(lockKey))) {
        // 第二步： 若在此时，这把锁突然不是这个客户端的，则会误解锁
        jedis.del(lockKey);
    }
}

• 代码解释：
  • 通过 requestId 判断加锁与解锁是不是同一个客户端和 jedis.del(lockKey) 两步不是原子操作，理论上会出现在执行完第一步if判断操作后锁其实已经过期，并且被其它线程获取，这是时候在执行jedis.del(lockKey)操作，相当于把别人的锁释放了，这是不合理的。
  • 当然，这是非常极端的情况，如果unLock方法里第一步和第二步没有其它业务操作，把上面的代码扔到线上，可能也不会真的出现问题，原因第一是业务并发量不高，根本不会暴露这个缺陷，那么问题还不大。
  • 但是写代
    码是严谨的工作，能完美则必须完美。针对上述代码中的问题，提出改进。
• 代码改进：

public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

• 代码解释：
  • 通过 jedis 客户端的 eval 方法和 script 脚本一行代码搞定，解决方法一中的原子问题

3.2 基于Zookeeper

还是积分消费与积分累加的例子：

• 事件A和事件B同时需要进行对积分的修改操作，两台机器同时进行，正确的业务逻辑上让一台机器先执行完后另外一个机器再执行，要么事件A先执行，要么事件B先执行，这样才能保证不会出现A:2 -> B:2 -> A:3 -> B:3这种积分越花越多的情况

基于 ZooKeeper 的分布式锁实现原理

• 一个机器接收到了请求之后，先获取 zookeeper 上的一把分布式锁（zk会创建一个 znode），执行操作；然后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等待，等第一个机器执行完了方可拿到锁。
• 使用 ZooKeeper 的顺序节点特性，假如我们在/lock/目录下创建3个节点，ZK集群会按照发起创建的顺序来创建节点，节点分别为/lock/0000000001、/lock/0000000002、/lock/0000000003，最后一位数是依次递增的，节点名由zk来完成。
• ZK中还有一种名为临时节点的节点，临时节点由某个客户端创建，当客户端与ZK集群断开连接，则该节点自动被删除。EPHEMERAL_SEQUENTIAL为临时顺序节点。
• 根据ZK中节点是否存在，可以作为分布式锁的锁状态，以此来实现一个分布式锁，下面是分布式锁的基本逻辑：
  • 客户端调用create()方法创建名为“/dlm-locks/lockname/lock-”的临时顺序节点。
  • 客户端调用getChildren(“lockname”)方法来获取所有已经创建的子节点。
  • 客户端获取到所有子节点path之后，如果发现自己在步骤1中创建的节点是所有节点中序号最小的，就是看自己创建的序列号是否排第一，如果是第一，那么就认为这个客户端获得了锁，在它前面没有别的客户端拿到锁。
  • 如果创建的节点不是所有节点中需要最小的，那么则监视比自己创建节点的序列号小的最大的节点，进入等待。直到下次监视的子节点变更的时候，再进行子节点的获取，判断是否获取锁。
• 释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可，不过也仍需要考虑删除节点失败等异常情况。

3.3 基于数据库，比如Mysql。

方法一：

• 利用 Mysql 的锁表，创建一张表，设置一个 UNIQUE KEY 这个 KEY 就是要锁的 KEY，所以同一个 KEY 在mysql表里只能插入一次了，这样对锁的竞争就交给了数据库，处理同一个 KEY 数据库保证了只有一个节点能插入成功，其他节点都会插入失败。
• DB分布式锁的实现：通过主键id的唯一性进行加锁，说白了就是加锁的形式是向一张表中插入一条数据，该条数据的id就是一把分布式锁，例如当一次请求插入了一条id为1的数据，其他想要进行插入数据的并发请求必须等第一次请求执行完成后删除这条id为1的数据才能继续插入，实现了分布式锁的功能。
• 这样 lock 和 unlock 的思路就很简单了，伪代码：

def lock ：
    exec sql: insert into locked—table (xxx) values (xxx)
    if result == true :
        return true
    else :
        return false

def unlock ：
    exec sql: delete from lockedOrder where order_id='order_id

方法二：

• 使用流水号+时间戳做幂等操作，可以看作是一个不会释放的锁。

四、ZK和Reids的区别，各自有什么优缺点？

Reids

• Rdis只保证最终一致性，副本间的数据复制是异步进行（Set是写，Get是读，Reids集群一般是读写分离架构，存在主从同步延迟情况），主从切换之后可能有部分数据没有复制过去可能会「丢失锁」情况，故强一致性要求的业务不推荐使用Reids，推荐使用zk。
• Redis集群各方法的响应时间均为最低。随着并发量和业务数量的提升其响应时间会有明显上升（公有集群影响因素偏大），但是极限qps可以达到最大且基本无异常

ZK

• 使用ZooKeeper集群，锁原理是使用ZooKeeper的临时节点，临时节点的生命周期在Client与集群的Session结束时结束。因此如果某个Client节点存在网络问题，与ZooKeeper集群断开连接，Session超时同样会导致锁被错误的释放（导致被其他线程错误地持有），因此ZooKeeper也无法保证完全一致。
• ZK具有较好的稳定性；响应时间抖动很小，没有出现异常。但是随着并发量和业务数量的提升其响应时间和qps会明显下降。

如何选择

• 使用分布式锁，必须满足两个条件之一：

  • 业务本身不要求强一致性，可以接受偶尔出现锁被其他线程重复获取。
  • 业务本身要求强一致性，如果锁被错误地重复获取，必须有降级方案保证一致性。

• 无论ZooKeeper与Redis，在极端情况下（例如整个ZK集群失效，例如Reids的Master失效而Slave没完全同步）都会存在正在被加锁的资源被重复加锁的问题。这种不可靠的概率极低，主要依赖于Zk集群与Redis集群。

• 针对分布式锁的实现方法，使用哪种需要取决于业务场景，如果系统接口的读写操作完全是基于内存操作的，那显然使用Redis更合适，Mysql表锁or行锁明显不合适。