第九章：一致性与共识
1. 一致性问题的范围
一致性不是单一概念，常见语义包括副本新鲜度、事务隔离、因果顺序与全局决策一致。设计前必须先明确业务真正需要哪一种保证。
2. 线性一致性（Linearizability）
2.1 定义
线性一致性要求系统看起来像“只有一个副本”，且每次读都能看到最近一次已完成写入。
2.2 与可串行化的区别
- 可串行化：关注事务之间是否等价于某个串行顺序。
- 线性一致性：关注操作顺序是否符合真实时间先后。
两者组合得到严格可串行化（Strict Serializability）。
2.3 代价与边界
线性一致通常需要跨节点同步确认，延迟上限受网络往返时间约束。网络分区时，系统必须在一致性与可用性之间取舍。
3. 顺序与因果
3.1 因果关系
因果顺序是偏序，不要求全局唯一顺序，但要求“先因后果”。很多业务只需要因果一致，不需要线性一致。
3.2 序列号与逻辑时钟
- 物理时钟难以可靠表达因果。
Lamport时间戳可构建全序近似，但不足以单独解决唯一性与冲突裁决。- 向量时钟可表达并发关系，适合冲突检测。
3.3 全序广播
全序广播要求所有节点以相同顺序交付消息。它与共识问题在能力上等价，是状态机复制的核心基础。
4. 分布式事务与原子提交
4.1 两阶段提交（2PC）
2PC 通过“Prepare/Commit”保证跨节点原子提交，但协调者故障会导致参与者阻塞。
4.2 XA 的工程现实
XA 能统一异构资源事务，但部署复杂、时延高、故障恢复困难。高并发场景常采用本地事务 + 事件驱动补偿替代全局强事务。
4.3 三阶段提交的局限
3PC 依赖较强同步网络假设，现实网络环境下难以提供预期收益。
5. 共识算法
5.1 共识目标
在节点故障下，集群仍需对某个值达成一致，并保证一致性、有效性与最终可决定性。
5.2 主流算法
Paxos、Raft、Zab、VSR 的核心思想一致：
- 用任期（
term/epoch）避免旧主继续写入。 - 用多数派
quorum保证新旧决策交集。 - 用复制日志驱动状态机一致。
5.3 成本
共识组通常规模较小（如 3 或 5 节点），追求的是强一致控制面，而不是海量数据面扩展。
6. 协调服务（ZooKeeper / etcd）
6.1 定位
协调服务不是通用数据库，而是提供线性一致小数据存储与协调原语：锁、选主、配置、服务发现。
6.2 常见能力
- 原子读改写。
- 单调递增版本号（可用于
fencing token）。 - 临时节点与会话失效检测。
- 变更订阅通知。
6.3 设计建议
把复杂共识能力“外包”给成熟协调系统，业务只消费稳定原语，可显著降低协议实现风险。
7. 实务建议
- 先按业务语义定义一致性级别，再选算法与系统。
- 强一致控制面与高吞吐数据面分层设计。
- 对外显式声明一致性承诺，避免“默认强一致”的错误预期。