分布式锁是什么？

分布式锁是一种在分布式系统中用于协调多个节点访问共享资源或执行互斥操作的机制。它的核心目标是确保在分布式环境中，同一时间只有一个节点（或进程）能够访问某个共享资源，避免数据不一致或竞争条件。类似于单机系统中的锁（如 Java 的 synchronized 或 ReentrantLock），但分布式锁需要解决多节点间的同步问题，因此更复杂。

通俗来说，分布式锁就像一个“共享钥匙”：多个节点（或服务）想要操作某个资源时，必须先拿到这把钥匙。一次只能有一个节点持有钥匙，用完后释放，别的节点才能抢到。

分布式锁的机制

分布式锁通常依赖一个中心化的协调服务（如 ZooKeeper、Redis、etcd）或某种一致性协议来实现。以下是分布式锁的典型工作流程：

  1. 获取锁：

    • 节点 A 尝试向协调服务（如 Redis）请求锁，比如通过 SETNX（set if not exists）命令在 Redis 中设置一个键（如 lock:resource1），并带上过期时间（防止死锁）。
    • 如果键设置成功，节点 A 获得锁；如果键已存在，说明其他节点持有锁，节点 A 需要等待或重试。

  2. 执行操作：

    • 节点 A 持有锁后，安全地访问共享资源（比如修改数据库中的某条记录）。
    • 其他节点（如 B、C）尝试获取锁时会失败，只能等待。

  3. 释放锁：

    • 节点 A 完成操作后，主动释放锁（比如删除 Redis 中的键）。
    • 其他节点检测到锁被释放后，重新竞争锁。

  4. 防止死锁：

    • 为了避免节点崩溃导致锁无法释放，分布式锁通常会设置过期时间（TTL）。如果节点 A 持有锁但崩溃，锁会在过期后自动释放。
    • 为了确保安全，锁还会绑定节点标识（如 UUID），释放锁时检查是否是自己持有的锁。

  5. 重试机制：

    • 如果节点 B 没抢到锁，可以通过轮询、订阅通知（如 ZooKeeper 的 Watch 机制）或阻塞等待来重试获取锁。

分布式锁的常见实现

  1. 基于 Redis：

    • 使用 SETNX 命令设置锁，结合 EXPIRE 设置过期时间。
    • 释放锁时使用 Lua 脚本确保只有锁的持有者能删除键。
    • 优点：高性能、简单易用。
    • 缺点：单点故障风险（需用 Redis 集群缓解），锁过期时间难以设置（过短可能导致锁提前失效，过长可能影响效率）。

  2. 基于 ZooKeeper：

    • 使用临时顺序节点（如 /lock/resource1）实现锁。
    • 节点竞争创建顺序节点，序号最小的节点获得锁，其他节点监听前一个节点的状态。
    • 优点：强一致性，适合高可靠性场景；支持 Watch 机制，效率高。
    • 缺点：部署和维护较复杂，性能略低于 Redis。

  3. 基于 etcd：

    • 利用 etcd 的租约（Lease）和键值存储实现锁。
    • 节点通过租约创建键，获取锁；租约到期自动释放。
    • 优点：强一致性，支持分布式事务。
    • 缺点：性能和复杂度与 ZooKeeper 类似。

  4. 基于数据库：

    • 通过数据库的唯一约束（如插入唯一记录）或事务实现锁。
    • 优点：简单，适合已有数据库的场景。
    • 缺点：性能较低，数据库压力大。

与 Raft 的关系和对比

你提到实现过 Raft 集群，Raft 是一种分布式一致性协议，主要用于保证数据复制和状态机的一致性（比如在分布式数据库或配置中心中）。分布式锁和 Raft 的目标不同，但有一定联系：

  • 共同点：

    • 两者都用于分布式系统，解决多节点协作问题。
    • Raft 也可以用来实现分布式锁（比如基于 Raft 构建的键值存储，类似 etcd 的方式）。
    • 都需要处理节点故障、脑裂等问题。

  • 不同点：

    • Raft 关注的是数据一致性（如日志复制），而分布式锁关注的是互斥访问（如控制谁能修改资源）。
    • Raft 通常用于状态机复制场景（如分布式数据库），而分布式锁更常用于短暂的资源访问控制（如秒杀系统）。
    • Raft 的实现复杂度较高（需要选举 Leader、复制日志等），而分布式锁的实现可以更轻量（比如 Redis 实现只需几个命令）。

分布式锁的优势

  1. 互斥性：

    • 保证分布式环境中同一时间只有一个节点能操作共享资源，避免数据竞争和不一致。

  2. 高可用性：

    • 通过协调服务（如 Redis 集群、ZooKeeper 集群），分布式锁可以在节点故障时继续工作。

  3. 灵活性：

    • 分布式锁可以用于多种场景，如分布式任务调度、秒杀系统、分布式事务等。

  4. 防止死锁：

    • 自动过期机制和节点标识检查可以有效避免死锁问题。

  5. 可扩展性：

    • 分布式锁支持动态扩展，新增节点不会破坏锁的机制。

分布式锁的典型应用场景

  1. 秒杀系统：

    • 确保库存扣减操作是线程安全的，避免超卖。
    • 比如用 Redis 分布式锁控制对库存键的访问。

  2. 分布式任务调度：

    • 在多个节点运行的任务中，确保某个任务只被一个节点执行（如 Quartz 集群中的任务调度）。

  3. 分布式事务：

    • 在分布式系统中协调多个服务的事务操作，确保一致性。

  4. 配置管理：

    • 确保配置更新时只有一个节点能修改配置（如 ZooKeeper 的分布式配置管理）。

通俗比喻

想象一个图书馆，只有一本珍贵书籍（共享资源）。图书馆有很多读者（分布式节点），但一次只能有一个读者借阅这本书。为了避免争抢，图书馆用一个登记本（分布式锁服务）记录谁在借书：

  • 读者 A 去登记本上写下自己的名字（获取锁），其他读者（B、C）看到名字已存在，只能等待。
  • 读者 A 读完书后擦掉自己的名字（释放锁），其他人再去抢着登记。
  • 如果读者 A 忘了还书，登记本会自动清除名字（锁过期），让其他人有机会借书。

注意事项

  1. 锁的粒度：

    • 锁的范围要尽量小，避免锁住过多资源，影响并发性能。

  2. 过期时间设置：

    • 过期时间要合理，过短可能导致锁提前失效，过长可能导致其他节点等待过久。

  3. 性能瓶颈：

    • 分布式锁依赖协调服务（如 Redis、ZooKeeper），其性能和可靠性会影响锁的效率。

  4. 一致性要求：

    • 如果需要强一致性，推荐 ZooKeeper 或 etcd；如果追求高性能，Redis 是更好的选择。

总结

分布式锁是分布式系统中实现互斥访问的利器，通过协调服务（如 Redis、ZooKeeper、etcd）确保多节点间的同步。相比你熟悉的 Raft，分布式锁更专注于资源访问控制，机制更轻量，应用场景更灵活。它的优势在于互斥性、高可用性和防止死锁，广泛用于秒杀、任务调度等场景。如果你想尝试实现，可以从 Redis 的 SETNX 开始，结合 Raft 的经验，理解起来会更轻松