一致性模型解决什么问题
多副本存储要在「读写立即可见」与「系统始终可写」之间取舍。强一致要求写入被确认后，任何节点的读取都返回该值，实现方式通常是多数派写或同步复制，代价是写路径需要等待足够多的副本确认，延迟更高，且当可用副本不足时会拒绝写入。最终一致则允许副本之间短暂不一致，写入先在局部生效再异步传播，代价是不同节点可能读到旧值，甚至出现读到「更旧」数据的现象。实践中的多数系统处于两者之间，例如提供读己之写、单调读或按会话保证，这些折中能覆盖大部分业务需求，同时保留更高的可用性。
模型对照
| 维度 | 强一致 | 最终一致 |
|---|---|---|
| 写入确认 | 需多数或全部副本确认 | 主副本确认即可返回 |
| 读取新鲜度 | 任何节点读到最新值 | 可能读到旧值，收敛有延迟 |
| 延迟 | 较高，受最慢副本影响 | 较低，路径更短 |
| 分区容忍 | 副本不足时可能拒绝写 | 通常保持可写 |
| 应用复杂度 | 较低，按单副本思维开发 | 需处理旧读、冲突与重试 |
基本信息
| 强一致前提 | 多数派可用，网络延迟稳定 |
|---|---|
| 最终一致收敛条件 | 写入停止后副本最终同步到相同状态 |
| 常见折中 | 读己之写、单调读、会话一致性 |
| 应用补偿 | 幂等写入、版本号或时间戳判新旧、冲突解决策略 |
| 选择依据 | 业务能否容忍读到旧数据，以及可用性与延迟目标 |
典型使用场景
- 账务与库存等强一致诉求：写入确认后必须立即对所有读取可见
- 跨站点双活：多数派复制影响延迟，需评估链路时延与站点数量
- 内容分发与静态资源：最终一致即可，换取更低延迟与更高可用性
- 社交动态与推荐：短暂陈旧可接受，优先保证可写与响应速度
- 跨地域备份与对象复制：异步复制为主，需明确恢复点目标
一致性级别常可按请求设置：同一套系统里，关键操作走强一致、浏览类操作走最终一致，是兼顾体验与成本的常见做法。配置前需确认实现是否真正支持该级别，而非仅在接口上标注。
把最终一致当成「几乎一致」是常见误区：网络分区或复制延迟高时，差窗可能持续较长时间。涉及金额、额度与状态机的业务若使用最终一致，必须在应用层设计冲突检测与人工兜底。