聊聊三种常用的分布式锁

大家好，我是橘子，今天我们聊聊分布式锁。

平时我们在 APP 上抢某件商品时，手指疯狂点击下单，但是只会生成一个订单，为什么呢？

因为对用户下单加了一个锁，避免用户重复下单。而在分布式场景，订单可以看作一个共享资源，所以这个锁可以叫做分布式锁。

一般来讲，分布式锁有三种实现方式：

• 基于数据库的分布式锁
• 基于 redis 的分布式锁
• 基于 Zookeeper 的分布式锁

1 基于数据库的分布式锁

基于数据库实现分布式锁有很多实现，这里介绍其中一种。其核心思想是：

在数据库中创建一个表，表中添加 方法名 等字段，并 对方法名字段添加唯一索引，如果要对某个方法加锁，则使用这个方法名向表中插入数据，成功插入则加锁成功，方法执行完后删除对应的行数据释放锁。[1]

1.1 创建表

CREATE TABLE `t_database_lock` (
  `id` bigint NOT NULL COMMENT '主键',
  `method_name` varchar(50) COLLATE utf8_bin NOT NULL DEFAULT '方法名字',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最近更新时间'
  PRIMARY KEY(`id`),
  UNIQUE INDEX `uk_t_database_lock_mname`(`method_name`) USING BTREE COMMENT '方法名唯一索引',
  INDEX `idx_t_accounting_balance_account_utime`(`update_time`) USING BTREE COMMENT '更新时间索引',
  INDEX `idx_t_accounting_balance_account_ctime`(`create_time`) USING BTREE COMMENT '创建时间索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

1.2 伪代码实现

主流程如下：

public void execute(String methodName) {
    try {
        if (lock(methodName)) { // 加锁
            // 你的业务逻辑
            run();
        }
    } finally {
        unlock(); // 释放锁
    }
}

lock() 方法的实现的伪代码如下：

private boolean lock(String methodName) {
    try {
        // 插入一条数据
        int count = "INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '需要加锁的methodName');";
        if (count == 1) { // 1 表示插入成功
            return true;
        }
        return false;
    } catch (Exception e) {
        return false;
    }
    return false;
}

unlock() 方法实现的伪代码如下：

private void unlock() {
    String sql = "delete from method_lock where method_name = '#{methodName}';";
    // 执行删除操作
    doExecute(sql);
}

它的优点是实现简单，但是有以下缺点：

1. 读取写入性能低，资源开销较大，不适合并发量很高的场景。
2. 可靠性较低，因为数据库的可用性会直接影响到分布式锁的可用性，所以数据库需要双机部署、数据同步、主备切换。
3. 没有锁失效机制。如果在成功插入一条数据后，服务器宕机了，导致这条数据没有删除，服务恢复后一直获取不到锁。解决方式是可以在表中新增一例失效时间，定时清除这些失效数据。
4. 锁逻辑简单，不具备阻塞锁等高级功能。

2 基于 redis 的分布式锁

redis 分布式锁的好处是性能好，实现也较为方便。

2.1 setnx + expire

• setnx 即 Set if Not Exists，如果 redis 存在这个 key，setnx 返回0，加锁失败；否则返回1，加锁成功。
• expire 用来设置 redis key 的过期时间，避免这个锁一直存在，造成无法加锁的问题。

实现伪代码如下：

if (jedis.setnx(key) == 1) { // 加锁成功
    expire(key, 100);
    try {
        doSomething(); //业务处理
    } catch (Exception e) {

    } finally {
        jedis.del(key); // 释放锁
    }
}

这个是基本的实现，但是会有一个问题：如果 setnx 执行结束，进程中断了，没有执行 expire 代码，导致 key 没有设置过期时间，别的线程就永远获取不到这个锁了。

2.2 setnx 同时设置过期时间

基于以上问题，我们可以将 redis 的 value 利用起来，将 jedis.setnx(key) 改为 jedis.setnx(key, ${过期时间})，加锁的伪代码如下[2]：

public boolean lock(String key, Long expireTime) {
    Jedis jedis = new Jedis();
    //系统时间 + 设置的过期时间
    long expires = System.currentTimeMillis() + expireTime;
    String expiresStr = String.valueOf(expires);

    // 如果当前锁不存在，返回加锁成功
    if (jedis.setnx(key, expiresStr) == 1) {
        return true;
    }
    // 如果锁已经存在，获取锁的过期时间
    String currentValueStr = jedis.get(key);

    // 锁过期
    if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
        // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间
        String oldValueStr = jedis.getSet(key, expiresStr);
        if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
            // 只有上一个锁的过期时间和当前过期时间相同才可加锁
            return true;
        }
    }

    return false;
}

以上的实现方式避免了锁一直存在的问题，但是仍然有缺点：

1. 过期时间使用 System.currentTimeMillis() 生成，意味着客户端时间必须同步。
2. 没有辨别客户端的机制，可能 A 机器加了锁，被 B 机器解锁了。
3. 并发情况下，多个机器同时加锁，只有一个会加锁成功。

2.3 将 redis value 设置为客户端标识

通过以上分析，我们既希望 redis 设置 key 和 expire 同时进行，又希望 redis 加锁解锁时能识别客户端。

因此我们将客户端加锁时，生成一个唯一 ID 作为 redis 的 value，在进行锁操作时先校验一下客户端是否一致，在进行锁操作。redis 的 set() 方法可以满足要求。

流程的伪代码如下：

public void execute() {
    Jedis jedis = new Jedis();
    String key = "key";
    String uuid = "uuid";
    if ("1".equals(jedis.set(key, uuid, "NX", "EX", 100))) { //加锁
        try {
            doSomething(); //业务处理
        } finally {
            //判断是不是当前线程加的锁,是才释放
            if (uuid.equals(jedis.get(key))) {
                jedis.del(key); //释放锁
            }
        }
    }
}

以上实现已经不错了，可以满足大部分场景。但是还有一个问题：过期时间是个不确定因素，你很难设置一个合适的过期时间，使得锁既在业务执行后释放，又不至于太长导致其他线程获取失败。

2.4 Redisson

Redisson 可以解决上面的问题，它的原理是在加锁成功后启动一个看门狗，在线程持有锁期间不断延长 key 的生存时间，如此一来可解决锁在业务执行完之前就释放的问题。

3 Zookeeper 分布式锁

当使用 ZooKeeper 实现分布式锁时，可以按照以下步骤进行操作：

1. 每个客户端连接到 ZooKeeper 服务器。
2. 每个客户端在 ZooKeeper 上创建一个临时顺序节点作为锁节点。
3. 客户端获取锁的方式是判断自己创建的节点是否是当前所有锁节点中最小的。
4. 如果客户端创建的节点是最小节点，表示该客户端获得了锁，可以执行关键区域的代码。
5. 如果客户端创建的节点不是最小节点，则需要监听比自己创建节点次小的节点。
6. 当监听到次小节点被删除时，客户端重新检查自己创建的节点是否是当前所有锁节点中最小的。如果是，则获得了锁，可以执行关键区域的代码。
7. 当客户端完成了关键区域的操作后，释放锁，即删除自己创建的节点。

这样，通过 ZooKeeper 的临时顺序节点和监听机制，可以实现一个简单的分布式锁。每个客户端在创建节点时，会根据节点名称的顺序来确定是否获得了锁。如果创建的节点是最小节点，则表示该客户端获得了锁，可以执行关键区域的代码。其他客户端则通过监听比自己创建的节点次小的节点来等待锁的释放，从而实现分布式的互斥访问。

总结

以上实现方式都不是完美的，在实际生产中要合理评估，选择适合自己的方案。

性能

redis > zookeeper >= 数据库

可靠性

zookeeper > redis > 数据库

实现复杂度

zookeeper > redis > 数据库

[1] 什么是分布式锁？实现分布式锁的三种方式
[2] 面试官又问我分布式锁。。。