一致性模型
一致性模型是分布式系统的“契约”：读能看到多新的写。面试主线：谱系、各模型语义、实现机制。
一致性谱系
从强到弱: 性能与一致性的权衡
| 模型 | 语义 | 例子 |
|---|---|---|
| 线性一致 | 读必见最新写（全局实时序） | 单机数据库、etcd |
| 顺序一致 | 各进程看到相同顺序（不一定实时） | 部分分布式系统 |
| 因果一致 | 有因果关系的操作有序 | 分布式会话 |
| 最终一致 | 无新写后，副本收敛到相同 | DNS、缓存、异步复制 |
线性一致性（必考）：系统表现得像单机一样，所有操作有全局实时顺序。实现代价高（要共识协议同步），但语义最简单（“读到了刚写的”）。
为什么难
- 副本延迟：写主节点，读从节点可能读旧（复制延迟）
- 时钟问题：无全局时钟，无法定义“最新”
- 冲突：并发写不同副本，谁赢？（见下面）
实现机制
| 机制 | 提供 | 代价 |
|---|---|---|
| 共识协议（Raft/Paxos） | 线性一致（写入经多数派） | 延迟（每次写等多数确认） |
| 同步复制 | 主备都确认 | 延迟，主备一致 |
| 异步复制 | 低延迟 | 读旧、可能丢 |
| 版本向量/时间戳 | 冲突检测 | 需要合并逻辑 |
| 读己之写 | 会话内读最新 | 部分保证 |
读己之写（考点）：用户提交后刷新页必须看到自己的写入。实现：会话路由到主节点、版本号检查、Cookie 标记。
强一致 vs 最终一致的选型
| 场景 | 需要 | 方案 |
|---|---|---|
| 订单、支付、库存扣减 | 强一致 | 主库读写 + 事务 |
| 排行榜、计数 | 可容忍最终一致 | 异步 + 对账 |
| 缓存 | 最终一致 | Cache Aside（见缓存一致性篇） |
| 配置、分布式锁 | 强一致 | etcd（Raft） |
面试话术：先定业务需要哪个模型，再选机制。强一致贵（延迟/复杂度），只在数据正确性攸关处用。
面试追问
- 一致性谱系？ 线性（实时序）→ 顺序 → 因果 → 最终。由强到弱
- 线性一致是什么？ 系统表现得像单机：所有操作全局实时序，读必见最新写。etcd 级别
- 怎么实现强一致？ 共识协议（多数派确认）或同步复制。代价是延迟
- 读己之写？ 用户必须看到自己刚写的。会话路由主节点或版本检查
- 什么时候容忍最终一致？ 数据正确性不攸关、可对账的场景。强一致只在必须处用