协调服务与实践模式

共识（→ 共识：Paxos 与 Raft）之上，工程界把常见协调模式做成了服务与套路：协调服务（ZooKeeper/etcd）、租约、幂等与重试、Saga。本章是分布式系统的工程模式集。

协调服务

基于共识的协调服务提供三类原语：

用对场景：协调服务是元数据工具，不是数据存储——数据量大或写入频繁（监控指标、消息）会压垮它（共识的写代价，每写一轮多数派）。锁与选举、配置、命名是它的正确用武之地。

租约（lease）解决"持锁者死了"的问题：锁/授权带有效期，过期自动失效——持锁者崩溃后，系统最多等租约过期（不用等它"承认死亡"）。

租约的正确性依赖时钟：过期判定依赖时间（或心跳共识）——时钟漂移会让"以为过期"实际没过期；
** fencing token**：分布式锁需要 fencing token 才安全——每次授予锁时递增的编号，下游校验"只有最新 token 的写有效"——防止过期的持锁者复活后继续写（GC 停顿让它"死而复生"）。没有 fencing token 的分布式锁不是锁，是"大概互斥"。

持锁者 A 拿到锁，token=33 → 长时间 GC 停顿
租约过期 → B 拿到锁，token=34
A 醒来继续写（带着 token=33）→ 存储层拒绝（33 < 34）✔

分布式通信必然失败：超时后你不知道"对方做没做"——重试是标准应对，而重试必须幂等：

幂等（idempotency）：同一操作执行多次与一次效果相同——转账"加 100"不幂等，"设置余额为 100"幂等；
实现幂等：幂等键（idempotency key）——客户端生成唯一键，服务端去重（支付系统的标准做法）；条件写（CAS、带版本号）；
重试必须配退避与抖动：**指数退避（exponential backoff）**避免重试风暴，**抖动（jitter）**避免同步重试的波峰——没有退避的重试是自我 DoS。

精确一次（exactly-once）投递不存在于纯网络层：两将军问题——你无法确认"恰好一次"到达。实际的等价物：

\text{精确一次} = \text{至少一次（at-least-once）} + \text{幂等}

"精确一次 = 至少一次 + 幂等"——工程上的"恰好一次"都是这个组合，不要在网络上找奇迹。

微服务间没有 2PC（跨服务的分布式事务代价太高，→ 复制与分片），Saga 模式替代：长事务拆成一系列本地事务，每个配一个补偿操作——失败时逆序执行补偿：

订机票 ✓ → 订酒店 ✓ → 订租车 ✗
补偿：退酒店 ← 退机票