一致性模型是什么
一致性模型描述并发读写时系统向调用方提供的保证强度，从线性一致、顺序一致、因果一致到最终一致逐级放宽。模型越弱，通常可用性与延迟表现越好，但应用需要处理的不一致场景越多。选择模型时真正要回答的是两个问题：业务能容忍多旧的数据，以及出现冲突时由谁负责解决。
模型谱系
| 模型 | 保证 | 典型代价 |
|---|---|---|
| 线性一致 | 读写像在单副本上实时执行 | 跨节点协调，延迟高，分区时可能不可用 |
| 顺序一致 | 所有节点看到相同的操作顺序 | 需要全局定序，实现复杂 |
| 因果一致 | 有因果关系的操作顺序保持一致 | 中等，常作为折中选择 |
| 读己之写 | 同一会话能读到自己的写入 | 实现简单，跨会话仍可能读到旧值 |
| 最终一致 | 停止写入后副本最终收敛 | 读到旧数据的窗口不可控 |
基本信息
| 常见弱化手段 | 读写分离、多副本异步复制、本地缓存 |
|---|---|
| 冲突解决 | 最后写入胜出、版本向量、业务规则合并 |
| 可观测 | 复制延迟、收敛时间纳入监控指标 |
| 与 CAP 关系 | 模型选择实质上是分区时取舍的具体化 |
| 文档要求 | 不写“强一致”这类模糊表述，写清具体模型与边界 |
典型使用场景
- 架构评审：明确每条链路的一致性要求，而不是笼统要求强一致
- 读写分离设计：为读延迟设定可接受的窗口并监控
- 跨地域部署：为就近读取接受一定延迟，用会话内读写保证体验
- 缓存策略：明确缓存失效时间与允许的陈旧窗口
- 多副本数据库选型：按业务能否处理冲突挑选复制模式
- 故障恢复设计：为恢复期的不一致准备补偿与对账流程
端到端的一致性强度取决于链路中最弱的一段：调用链上任何一个环节用了最终一致存储，整体就不再是强一致。
文档只写“强一致”而不说明具体模型，评审时双方对同一句话的理解可能完全不同。