分布式协调原语：注册中心、ID生成、分布式锁

一致性的底层 + 三个最常用协调组件的技术对比

0. 读前必读：三个组件，其实是一套机制

你可能在各种框架文档里被"注册中心 / 雪花算法 / 分布式锁"这三个名字搞晕——它们看起来毫不相关。但底层它们共享同一套协调基础设施：

• 注册中心（ZooKeeper / Etcd / Nacos / Eureka / Consul）：回答"现在谁是活着的、谁提供什么服务"。
• ID 生成器（Snowflake / Leaf / UidGenerator）：回答"在分布式多机下，怎么给每个事件一个全局不重、最好还大致有序的编号"。
• 分布式锁（Redis / ZK / Etcd / DB）：回答"多机并发时，怎么保证同一时刻只有一个人能干某件事"。

1. 一致性基础：CAP / BASE / quorum / lease / watch / 共识

所有协调组件都建立在对"一致性与可用性如何取舍"的理解上。这一节是地基，后面三节都会回头引用它。

1.1 CAP 与"三选二"的真相

CAP 定理：一个分布式数据系统在网络分区（P，Partition）发生时，一致性（C，Consistency）和可用性（A，Availability）无法同时保证，只能二选一。

• C（一致性）：每次读取都能拿到"最新写入"的结果（线性一致 / 强一致）。所有副本立刻一致。
• A（可用性）：每个非故障节点收到的请求都必须在有限时间内返回（不管数据新不新）。
• P（分区容忍）：系统允许节点间网络断连（消息丢、延迟），仍能继续工作。

1.2 BASE 与最终一致

强一致（C）代价高（要多数派确认、要等复制）。很多场景并不需要"此刻绝对一致"，只要"过一会儿大家都会一致"就够了——这就是最终一致性。

BASE 是与之对应的设计哲学（与 ACID 相对）：

• BA（Basically Available，基本可用）：分区时允许降级（响应慢一点、部分功能关闭），但不整体挂掉。
• S（Soft state，软状态）：允许系统中间存在"不一致的中间态"，状态可以暂时不固定。
• E（Eventually consistent，最终一致）：在没有新写入后，经过一段时间，所有副本都会收敛到一致。

1.3 quorum：N/2+1 多数派

在"多副本"系统里，怎么判断一个值"算数"？靠法定人数（quorum）。设副本数 N，写法定数 W、读法定数 R。为保证读到的一定是"最新写过的"，经典约束是：

W + R > N

最常用的是 W = R = N/2 + 1（多数派）。意思是：写要被超过半数的节点确认，读也要从超过半数的节点读取并取最新——两者必然交集，所以读到的一定是含最新写的那一份。

• 例：N=5，则 W=3、R=3。写进 3 个、读问 3 个必撞上同一个人，最新值不会漏。
• 代价：N 越大，写延迟越高（要等多数派 ack）。这就是"一致性换性能"的具体体现。

1.4 lease 租约：带期限的授权

很多协调问题可归结为"谁有权做某事"（谁是主、谁能拿锁、谁还活着）。最优雅的机制之一是租约（lease）。

租约 = 一方给另一方一张"在 T 时间内有效的授权"。持有者在 T 内可放心行使权利；T 到期前必须续约（renew），否则授权自动失效。

• 心跳 vs 租约：心跳是"我还活着"的主动上报；租约是"你被授权活到 T 时刻"的被动倒计。注册中心的"临时节点 / 续约 TTL"本质就是 lease。
• 典型应用：ZK 临时节点的会话超时、Etcd 的 lease TTL、Redis 锁的过期时间、服务实例的"健康租约"。

1.5 watch / 回调订阅

协调系统的第二大能力是"状态变了通知我"，而不是让我不停去问（轮询）。这叫 watch / 订阅-推送。

• ZooKeeper watch：一次性触发器。你 watch 一个 znode，它一变就推一次事件，然后 watch 消失，需重新注册（否则会漏中间的变化）。这是一个经典"坑"。
• Etcd watch：支持持续监听 + 从某个 revision 开始回放，天然避免漏事件；还能 watch 一段前缀（目录级）。
• 推送 vs 拉取：watch 是"推"（服务端主动）；客户端也可定期拉全量兜底（Eureka 客户端就是拉取 + 缓存）。

1.6 共识简述：Raft / ZAB / Paxos

"多个节点对某个值的顺序达成一致"叫共识（consensus）。它是 CP 系统的引擎。

Raft（Etcd / Consul / Nacos-CP 用）

Raft 把共识拆成三个易理解的子问题：

1. 领导选举（Leader Election）：节点有 Follower / Candidate / Leader 三种角色。Follower 收不到 Leader 心跳超时 → 变 Candidate，投自己一票并要别人投票；拿到多数派票 → 当 Leader。每届叫一个 Term（任期），Term 单调递增，防止旧 Leader 乱发号。
2. 日志复制（Log Replication）：所有写先到 Leader；Leader 把命令作为"日志条目"追加，并复制到 Follower；收到多数派 ack 后，Leader 把它标记为已提交（committed），再应用到状态机，并通知 Follower 提交。
3. 安全性（Safety）：选举限制——只有"日志至少和多数派一样新"的节点才能当选；已提交的条目不会丢、不会改。这保证了线性一致。

ZAB（ZooKeeper 用）

ZAB（ZooKeeper Atomic Broadcast）是给 ZK 定制的原子广播协议，思想和 Raft 同类：也有 Leader、也有"事务提案 → 多数派 ack → 提交"。区别在于 ZAB 强调事务顺序的全局一致（ZXID 单调）和"崩溃恢复后保证已提交事务不丢"。简单说：Raft 是通用共识，ZAB 是 ZK 的专用共识，两者你中有我。

Paxos（思想源头）

Paxos 是共识理论的"祖师爷"，证明最难懂。它的核心思想一句话：" proposer 提编号，acceptor 只接受编号更大的提案；多数派确认即达成"。Raft / ZAB 都可看作"让 Paxos 好实现、好理解"的工程化版本。学习者不必死磕证明，记住"多数派 + 单调编号"即可。

2. 注册中心：把"共识 + 租约"用成了服务目录

2.1 注册中心到底在协调什么

微服务里，服务提供者（Server）上线要"报名"、下线要"销户"，服务消费者（Client）要知道"现在谁能调用"。注册中心要解决的三个底层问题，恰好对应三个原语：

2.2 ZooKeeper（ZAB + 临时节点 + watch）

• 一致性：CP，基于 ZAB 协议（类 Raft 的原子广播）。写必须经 Leader，多数派 ack 才提交。写性能受限于选主节点，且集群写吞吐随节点数上升反而下降（要同步更多人）。
• 数据模型：层级化的 znode 树。两种关键节点：
  • 持久节点：显式删除才消失，存"配置/目录"。
  • 临时节点（Ephemeral）：绑定客户端会话，会话断开（心跳/租约超时）即自动删除——天然实现"实例下线自动摘除"。
• watch：一次性触发器（见 §1.5），适合"节点增删改"事件。
• 典型用法：服务注册（临时节点）、配置中心、分布式锁（临时顺序节点，§4.3）、选主。

2.3 Etcd（Raft + lease + watch）

• 一致性：CP，基于 Raft（Go 实现，参考 JPaxos 思路）。和 ZK 一样写走 Leader + 多数派。
• 数据模型：扁平 key-value，但 key 有序、可按前缀组织成目录；带 revision（全局单调递增版本号）——这是它的杀手锏。
• lease：原生 lease 原语，key 绑定 lease TTL，可批量续约；超时自动删。
• watch：支持持续监听 + 从指定 revision 回放，不会漏事件；还能 watch 前缀。比 ZK 的"一次性 watch"更省心。
• 接口：gRPC / HTTP（v3 版），云原生标配（Kubernetes 的后端就是 Etcd）。

2.4 Nacos（AP Distro + CP Raft 双模型）

Nacos 的聪明之处在于"一套产品，两种一致性按需切换"：

• 服务注册 / 发现（AP）：默认走 Distro 协议——去中心化、每个节点负责一部分数据的最终一致复制；节点间 gossip 同步。可用性极高，适合"服务列表短暂不一致无伤大雅"的场景。
• 配置管理（CP）：走 Raft 保证配置强一致——配置错了可是大事，必须"看到的就是确定的"。
• 合一优势：注册中心 + 配置中心一个组件搞定，运维成本低。

2.5 Eureka（AP + 心跳 + 自我保护）

• 一致性：纯 AP。没有共识算法，节点间异步复制，允许短暂不一致。
• 健康判定：客户端心跳上报；服务端自我保护机制（Self-Preservation）——当短时间大量实例心跳丢失（很可能是网络分区，而非真挂了）时，不急着全剔除，宁可保留旧列表，避免"雪崩式误删"。
• 客户端缓存：Consumer 本地缓存服务列表，即使注册中心全挂，也能用旧列表继续调用（牺牲"新"换"活"）。

2.6 Consul（Raft + gossip + 多数据中心）

• 一致性：CP，基于 Raft 管内部状态；外加 gossip 协议做成员管理与多数据中心间的信息传播（gossip 是"随机告诉邻居、邻居再扩散"的 epidemics 式传播，最终全员知道）。
• 健康检查：内置多种健康探测（HTTP / TCP / 脚本），比纯心跳更丰富。
• 多数据中心：原生支持跨 DC，每个 DC 内部 Raft，DC 间 gossip 同步——对"全球部署"友好。
• 多合一：服务发现 + KV 配置 + 健康检查 + 多数据中心，开箱即用。

2.7 横向对比表与选型

3. 序列号 / ID 生成器：给每件事一个全局有序的"身份证"

分布式下，多机各自自增会撞号。ID 生成器的核心诉求：全局唯一、尽量趋势递增（让数据库索引更友好）、高性能、高可用。下面按"底层机制"从弱到强对比。

3.1 UUID 与数据库自增

• UUID：本地生成、无中心、高性能；但完全无序、字符串长、作为主键会让 B+ 树索引频繁分裂（插入随机，页分裂严重，性能差）。适合"不需要排序、只要唯一"的场景（如traceId）。
• 数据库自增（auto_increment）：简单、绝对有序；但单点瓶颈、扩容（分库分表）时步长难调、有性能上限。在分布式里基本被淘汰为"单机兜底"。

3.2 号段模式（Leaf-segment）

思路：数据库只负责"批发号段"，应用内存"零售发号"。

1. DB 里存 max_id, step；应用去取号段 [max_id+1, max_id+step]，并把 max_id 更新为 max_id+step。
2. 应用拿到号段后在本地内存原子自增发号，完全不碰 DB，性能极高。
3. 双 buffer 预取：当前号段用到一定比例（如 10%）时，后台线程异步去取下一个号段放进备用 buffer；当前号段耗尽直接切到备用，无发号停顿。

号段1: [1,    1000]  ← 当前在发（用到10%触发预取）
号段2: [1001, 2000]  ← 后台已取好，随时顶上

3.3 Snowflake 与时钟回拨

Twitter 提出的经典时间戳派方案，64 位整数，本地生成、无需中心、趋势递增。

• 为什么趋势递增：高位是时间，时间单调递增 → 整体 ID 随生成时间递增，对索引友好。但不是严格连续（不同机器、不同毫秒会跳）。
• 时钟回拨（核心坑）：如果机器时钟因为 NTP 校准往回跳，可能生成和"上一毫秒已发过的"相同的 ID → 重复。这是 Snowflake 最著名的致命弱点。
• workerId 分配：10 位机器 ID 不能重复。常见分配：手动配置 / 借 ZooKeeper 或 DB 申请 / 启动时报到抢号。分配错了会导致"不同节点用同一 workerId + 同一毫秒"撞号。

3.4 Redis incr 与 Leaf-snowflake / UidGenerator

• Redis incr：用 INCR 原子自增拿号，简单、快；但强依赖 Redis 可用，且是集中式（所有节点抢同一 key，有网络往返，吞吐受限），扩展开销大。本质是"把 DB 自增换成 Redis 自增"。
• Leaf-snowflake（美团）：在 Snowflake 上补两件事——① workerId 由 Leaf 服务统一从 DB / ZK 分配（解决手动配错）；② 缓存最近发号的时间戳，检测到时钟回拨时报警 + 拒绝发号（而非生成重复）。
• 百度 UidGenerator：Snowflake 变体，把 64 位重新切分（如 28 位秒级时间 + 22 位 workId + 13 位序列），并用"号段方式发 machineId"（启动时用数据库号段申请一个 workerId 区间），解决 workerId 分配与回拨保护。

3.5 横向对比

4. 分布式锁：把"互斥"这件事做对

4.1 锁必须满足的五个性质

4.2 Redis：set nx ex + 看门狗 + Redlock

基础版（单实例）：

SET lock_key unique_value NX EX 30   # 不存在才设(NX)，30秒过期(EX)
# 释放时务必用 Lua 脚本校验 value 再删，防误删别人的锁
if redis.call("get",KEYS[1])==ARGV[1] then return redis.call("del",KEYS[1]) end

• unique_value：每个客户端用唯一值（如 UUID+线程号），释放时校验"这是我的锁才删"，避免 A 的锁过期后 B 拿到、A 回来误删 B 的锁。
• 看门狗（Watchdog）续期：Redisson 等客户端在持锁期间起一个后台定时任务，每隔 TTL/3 就重置过期时间，只要客户端还活着，锁就不过期；客户端崩溃 → 定时任务没了 → 锁自然过期释放。完美解决"TTL 设多长"的两难。

Redlock（多实例，Antirez 提出）：为去掉"单 Redis 挂了锁就没了"的单点风险。向 N=5 个独立的 Redis master 依次加锁：

1. 记录起止时间，向 5 个节点都尝试 SET NX EX（各带独立短超时）；
2. 若拿到 ≥ N/2+1 = 3 个锁，且总耗时 < 锁有效期 → 认为加锁成功；
3. 失败/用完则向所有节点释放。

4.3 ZooKeeper / Etcd / 数据库 实现

• ZooKeeper（临时顺序节点）：在 /lock 下创建临时顺序节点（如 lock-00000001）。判断"自己是不是序号最小的那一个"：是 → 持锁；否 → 只 watch 比自己小一号的节点。前驱释放（节点删）才通知自己重试。羊群效应改进：只 watch 前驱而非全体，避免"一个释放、所有人被唤醒"的惊群。
• Etcd（lease + 原子 CAS + watch）：用事务 put key value with lease 且 prevKey 为空（CAS 抢锁）；持锁靠 lease 自动过期防死锁；watch 前驱 key 实现公平等待。比 ZK 更轻、watch 还能回放。
• 数据库（唯一索引 / 乐观锁）：
  • 唯一索引：INSERT 一条 (resource, owner) 记录，插入成功即获锁；释放即删。靠 DB 唯一约束保证互斥（最简单但 DB 压力大）。
  • 乐观锁 version：更新时带 where version = 旧值，版本不匹配则失败——适合"并发更新同一条数据"而非严格互斥锁场景。

4.4 fencing token：锁失效的终极补丁

即使有 TTL，仍可能因 GC 停顿 / 网络延迟，出现"A 持锁期间锁过期，B 拿到锁，然后 A 苏醒继续写"——两人都以为自己合法。fencing token 是根治这类的方案。

原理：每次成功加锁，锁服务发一个单调递增的整数 token。客户端去操作"受保护的资源（如存储）"时，必须带上 token；资源方（存储）记住"已处理的最大 token"，只接受 token > 已见最大值的写，旧 token 的写直接拒绝。

4.5 横向对比表

5. 一张图回到底层路线

把三个组件叠回"共识 + 租约"的内核，你会发现它们高度同源：

6. 一句话路线总结