MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

Redis分布式锁与Zookeeper分布式锁的对比

2024-10-276.0k 阅读

分布式锁概述

在分布式系统中，由于多个节点可能同时访问共享资源，为了保证数据的一致性和正确性，需要使用分布式锁来协调各个节点的访问。分布式锁是一种在分布式环境下实现互斥访问的机制，它允许多个进程或线程在不同的节点上竞争获取锁，只有获取到锁的进程或线程才能访问共享资源，其他进程或线程需要等待锁的释放。

Redis分布式锁

Redis分布式锁原理

Redis 是一个基于内存的高性能键值数据库，利用其单线程和原子操作的特性可以实现分布式锁。常见的实现方式是使用 SETNX 命令（SET if Not eXists），这个命令在键不存在时，将键的值设为给定值。如果键已经存在，该命令不做任何动作。 示例：假设我们要获取一个名为 lock_key 的锁，值为 lock_value，客户端可以执行 SETNX lock_key lock_value。如果命令返回 1，表示成功获取锁；如果返回 0，表示锁已被其他客户端持有。

在实际应用中，为了避免死锁，通常会给锁设置一个过期时间。可以通过 EXPIRE 命令来实现，例如 EXPIRE lock_key 10，表示设置 lock_key 的过期时间为 10 秒。但是这里存在一个问题，SETNX 和 EXPIRE 是两个分开的操作，不是原子性的。如果在执行 SETNX 成功后，还没来得及执行 EXPIRE 时，进程崩溃，那么这个锁就会永远存在，导致死锁。

为了解决这个问题，在 Redis 2.6.12 版本之后，可以使用 SET 命令的扩展参数来实现原子性的设置锁和过期时间。例如 SET lock_key lock_value NX EX 10，NX 表示只有键不存在时才设置，EX 表示设置过期时间为 10 秒。

Redis分布式锁代码示例（Java + Jedis）

import redis.clients.jedis.Jedis;

public class RedisDistributedLock {
    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "EX";

    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
        return LOCK_SUCCESS.equals(result);
    }

    public static void releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
        // 使用Lua脚本保证释放锁的操作原子性
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        jedis.eval(script, 1, lockKey, requestId);
    }

    public static void main(String[] args) {
        Jedis jedis = new Jedis("localhost", 6379);
        String lockKey = "my_distributed_lock";
        String requestId = "123456789";
        int expireTime = 10;

        if (tryGetDistributedLock(jedis, lockKey, requestId, expireTime)) {
            try {
                // 执行业务逻辑
                System.out.println("获取到锁，执行任务...");
            } finally {
                releaseDistributedLock(jedis, lockKey, requestId);
                System.out.println("释放锁");
            }
        } else {
            System.out.println("未获取到锁");
        }
        jedis.close();
    }
}

在上述代码中，tryGetDistributedLock 方法尝试获取分布式锁，releaseDistributedLock 方法用于释放锁。这里使用了 Lua 脚本来保证释放锁操作的原子性，因为在多线程环境下，如果不使用原子操作，可能会出现误释放其他线程锁的情况。

Redis分布式锁的优缺点

优点：

  1. 性能高：Redis 基于内存操作，速度快，适合高并发场景。
  2. 实现简单：使用 SET 命令及其扩展参数就可以很方便地实现分布式锁。
  3. 灵活性强：可以根据业务需求灵活设置锁的过期时间等参数。

缺点：

  1. 可靠性问题：虽然 Redis 是单线程处理命令，但在集群环境下，如果主节点在写入锁信息后，还未同步到从节点时发生故障，新的主节点可能会重新分配锁，导致锁的可靠性降低。
  2. 锁的续期复杂：如果业务执行时间较长，超过了锁的过期时间，需要进行锁的续期操作，这增加了实现的复杂性。

Zookeeper分布式锁

Zookeeper分布式锁原理

Zookeeper 是一个分布式协调服务框架，它维护着一个类似文件系统的树形结构数据，每个节点称为 znode。Zookeeper 分布式锁是基于 znode 的顺序性和临时节点特性来实现的。

当一个客户端尝试获取锁时，它会在 Zookeeper 的某个特定路径下创建一个临时顺序节点。例如，假设锁的根路径为 /locks，客户端创建的节点路径可能为 /locks/lock_0000000001。Zookeeper 会自动为每个新创建的节点分配一个唯一的单调递增的序号。

客户端获取锁的逻辑是：首先获取 /locks 路径下所有子节点，然后判断自己创建的节点序号是否是最小的。如果是最小的，则表示获取到锁；如果不是，则需要监听比自己序号小的前一个节点。当前一个节点被删除时，Zookeeper 会通知该客户端，客户端再次检查自己是否是最小序号的节点，若是则获取到锁。

当客户端释放锁时，只需要删除自己创建的临时节点即可。由于临时节点在客户端会话结束时会自动被 Zookeeper 删除，所以不用担心死锁问题。

Zookeeper分布式锁代码示例（Java + Curator）

import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class ZookeeperDistributedLock {
    private static final String CONNECT_STRING = "localhost:2181";
    private static final int SESSION_TIMEOUT_MS = 5000;
    private static final int CONNECTION_TIMEOUT_MS = 3000;
    private static final int BASE_SLEEP_TIME_MS = 1000;
    private static final int MAX_RETRIES = 3;

    public static void main(String[] args) throws Exception {
        CuratorFramework client = CuratorFrameworkFactory.builder()
               .connectString(CONNECT_STRING)
               .sessionTimeoutMs(SESSION_TIMEOUT_MS)
               .connectionTimeoutMs(CONNECTION_TIMEOUT_MS)
               .retryPolicy(new ExponentialBackoffRetry(BASE_SLEEP_TIME_MS, MAX_RETRIES))
               .build();
        client.start();

        String lockPath = "/locks/my_distributed_lock";
        InterProcessMutex lock = new InterProcessMutex(client, lockPath);

        try {
            if (lock.acquire(5, java.util.concurrent.TimeUnit.SECONDS)) {
                System.out.println("获取到锁，执行任务...");
                // 执行业务逻辑
            } else {
                System.out.println("未获取到锁");
            }
        } finally {
            if (lock.isAcquiredInThisProcess()) {
                lock.release();
                System.out.println("释放锁");
            }
            client.close();
        }
    }
}

在上述代码中，使用了 Curator 框架来简化 Zookeeper 分布式锁的实现。InterProcessMutex 类封装了获取锁和释放锁的逻辑。acquire 方法尝试获取锁，设置了等待超时时间为 5 秒。如果获取到锁，就可以执行相应的业务逻辑；释放锁时，通过 release 方法来完成。

Zookeeper分布式锁的优缺点

优点：

  1. 可靠性高：Zookeeper 采用了 Zab 协议保证数据的一致性和可靠性，即使部分节点故障，也能保证锁的正常工作。
  2. 安全性好：基于临时节点和顺序节点的特性，不会出现锁的误释放问题，并且可以通过监听机制保证公平性。
  3. 支持锁的自动释放：临时节点在客户端会话结束时自动删除，无需额外的操作来防止死锁。

缺点：

  1. 性能相对较低：Zookeeper 是基于磁盘存储的，并且节点之间需要进行数据同步，相比 Redis 基于内存的操作，性能会低一些，尤其是在高并发场景下。
  2. 实现相对复杂：相比 Redis 简单的 SET 命令实现，Zookeeper 分布式锁涉及到节点的创建、监听和删除等操作，代码实现相对复杂。

Redis与Zookeeper分布式锁对比

性能对比

在性能方面，Redis 分布式锁具有明显的优势。Redis 基于内存操作，并且单线程处理命令，执行速度非常快，能够满足高并发场景下对锁的快速获取和释放需求。而 Zookeeper 由于涉及到磁盘 I/O 和节点间的数据同步，性能相对较低。例如，在一个简单的分布式锁测试场景中，模拟 1000 个并发请求获取锁，Redis 可以在较短时间内完成大部分请求，而 Zookeeper 的响应时间会相对较长。

可靠性对比

Zookeeper 在可靠性方面表现更出色。Zookeeper 采用 Zab 协议，通过多节点的数据同步和选举机制，能够保证即使部分节点出现故障，整个系统仍然能够正常运行，锁的状态也能得到正确维护。而 Redis 在集群环境下，主从复制存在一定的延迟，如果主节点在写入锁信息后，还未同步到从节点时发生故障，可能会导致锁的可靠性问题。

实现复杂度对比

Redis 分布式锁的实现相对简单，使用 SET 命令及其扩展参数就可以轻松实现基本的分布式锁功能。虽然在释放锁等细节上可能需要一些额外的处理，如使用 Lua 脚本保证原子性，但总体来说代码量较少，易于理解和维护。而 Zookeeper 分布式锁的实现涉及到节点的创建、监听和删除等操作，并且需要考虑节点的顺序性和临时节点的特性，代码实现相对复杂，对开发人员的要求也更高。

锁的特性对比

  1. 公平性：Zookeeper 分布式锁基于顺序节点和监听机制，天然支持公平锁，每个客户端按照创建节点的顺序依次获取锁。而 Redis 分布式锁默认是非公平的，多个客户端竞争锁时，获取锁的顺序是不确定的。不过，通过一些额外的实现，如在 Redis 中使用有序集合（Sorted Set）来记录锁的申请顺序，可以实现公平锁，但这会增加实现的复杂性。
  2. 锁的自动释放：Zookeeper 的临时节点在客户端会话结束时会自动被删除，因此无需额外的操作来释放锁，能有效避免死锁问题。而 Redis 分布式锁需要手动设置过期时间来防止死锁，如果业务执行时间较长，还需要进行锁的续期操作，增加了实现的复杂度。

应用场景对比

  1. 高并发且对性能要求极高的场景：如果应用场景是高并发的读多写少，且对锁的获取和释放速度要求非常高，如抢购活动等，Redis 分布式锁是更好的选择。因为 Redis 的高性能能够快速响应大量的并发请求，满足业务对性能的要求。
  2. 对数据一致性和可靠性要求极高的场景：在一些对数据一致性和可靠性要求严格的场景，如分布式事务中的资源锁定，Zookeeper 分布式锁更为合适。Zookeeper 强大的可靠性和一致性保证机制，能够确保在各种情况下锁的状态正确，避免数据不一致问题。
  3. 对公平性有要求的场景：如果业务场景对锁的公平性有要求，希望每个客户端按照申请顺序依次获取锁，Zookeeper 分布式锁是首选。虽然 Redis 也可以通过一些手段实现公平锁，但 Zookeeper 基于顺序节点的实现更加简洁和自然。

综上所述，Redis 和 Zookeeper 分布式锁各有优缺点，在实际应用中需要根据具体的业务场景和需求来选择合适的分布式锁方案。如果对性能要求高，对可靠性要求相对较低，可以选择 Redis 分布式锁；如果对可靠性和数据一致性要求极高，对性能要求相对不是特别苛刻，Zookeeper 分布式锁是更好的选择。同时，还可以结合两者的优势，在不同的业务环节中使用不同的分布式锁，以达到最佳的系统性能和可靠性。