强一致、弱一致、最终一致有什么区别？
简化版
强一致要求写成功后，后续读一定能读到最新结果；弱一致不承诺读到最新值；最终一致允许短时间读到旧数据，但如果没有新的写入，副本最终会收敛一致。分布式系统不是一致性越强越好，越强通常延迟越高、可用性越低，越弱越容易扩展，但业务必须能接受短暂旧数据。
详细版
常见一致性模型可以这样理解：
| 模型 | 承诺 | 典型场景 |
|---|---|---|
| 强一致/线性一致 | 写成功后，后续读像读同一份最新数据 | 余额、库存、锁、配置中心 |
| 顺序一致 | 所有节点看到同一操作顺序，但不一定符合真实时间 | 复制状态机理论模型 |
| 因果一致 | 有因果关系的操作必须保序 | 评论与回复、协作文档 |
| 读己之写 | 自己写完自己一定能读到 | 发帖后自己刷新可见 |
| 单调读 | 已经看到新版本后，不会再看到更旧版本 | 会话粘滞读、多副本读 |
| 最终一致 | 短暂不一致，最终收敛 | DNS、搜索索引、点赞数、缓存 |
| 弱一致 | 不承诺什么时候读到最新 | 高性能缓存、监控采样 |
选择标准是旧数据的业务后果。旧余额、旧库存、旧权限会造成严重问题，就要强一致或关键路径强校验；点赞数、浏览量、搜索结果晚几秒可以接受，就适合最终一致。
完整版教学
一、一致性模型到底在回答什么
分布式系统里数据通常有多个副本。用户写入一个副本后，其他副本什么时候能看到？读请求如果打到不同节点，会不会读到不同版本？一致性模型就是系统对这些问题给出的承诺。
很多人把一致性理解成“所有数据完全一样”，这太粗了。真正要看的是读写时序：写成功的定义是什么？写成功之后的读是否必须看到最新？不同客户端看到的顺序是否一致？有因果关系的操作是否保序？这些承诺越强，实现成本越高。
二、强一致和线性一致为什么贵
强一致在工程语境中常指写成功后任意后续读都能看到最新值。理论上更严格的说法是线性一致：每个操作看起来都在调用开始和返回结束之间的某个瞬间生效，所有操作按真实时间排成一个全局顺序。
这很符合人的直觉，但代价明显。写入通常要经过 Leader、日志复制、多数派确认；读请求可能也要读 Leader，或者通过 ReadIndex 确认 Leader 没过期。节点故障或网络抖动时，为了不读错、不写错，系统宁可拒绝一部分请求。所以强一致常用于配置、锁、元数据、余额、库存等关键资源。
三、最终一致不是“随便不一致”
最终一致降低了承诺：写成功后，某些副本短时间可能仍是旧值，但只要没有新的写入，系统最终会同步到同一个值。DNS 解析、搜索索引、用户动态、点赞计数都常见这种模型。
关键在“最终”。工程上必须有复制协议、消息重试、补偿任务、冲突解决、对账修复。如果主库写完后消息丢了、下游永远不同步，那不是最终一致，而是数据丢失。最终一致是有机制、有时间窗口、有监控指标的。
四、业务常用的折中模型
很多体验问题不需要全局强一致，但需要比最终一致更强一点。比如“读己之写”：用户发布文章后，自己刷新必须能看到，别人晚几秒看到可以接受。可以通过写后读主库、短时间会话粘滞、客户端合并本地新内容实现。
“单调读”也很常见。用户已经看到订单已支付，下一次刷新不能又变成待支付。可以记录用户已见版本，后续读不低于该版本的副本。“因果一致”用于评论回复、协作文档等场景：回复不能先于原评论展示。
五、系统设计怎么落地选择
选择一致性时先问两个问题：第一，读到旧数据会造成什么损失？第二，业务能容忍多久的延迟？资金、库存、权限、锁通常不允许旧数据，至少关键写路径要强一致。内容流、排行榜、搜索索引可以最终一致，但要定义同步 SLA，例如 5 秒、1 分钟或 T+1 对账。
同一系统也会混合。商品详情缓存可以旧一点，但下单时必须回源校验库存；订单列表可以短暂延迟，但支付回调更新订单状态要可靠推进；用户自己发布的内容要读己之写，其他用户可以最终一致。
六、常见误区与追问
这道题不能只背概念，要把「一致性模型」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 强一致要求读到最新写入，最终一致允许短暂旧值，会话一致保证同一用户会话内读己之写 | 不要停在名词解释 |
| 流程机制 | 客户端写入数据 -> 副本间复制传播 -> 读取请求落到某个副本 -> 根据模型判断能否读旧值 -> 通过读主、版本号或会话粘滞提升一致性 | 说明触发方、参与方、状态变化和兜底 |
| 工程取舍 | 主库写入后 100ms 才复制到从库，这 100ms 内读从库可能读到旧值，就是最终一致窗口 | 分布式基础题不能只背概念，必须落到网络不可靠、节点会故障、数据有副本这些前提 |
一致性模型 面试拆解：
1. 客户端写入数据
2. 副本间复制传播
3. 读取请求落到某个副本
4. 根据模型判断能否读旧值
5. 通过读主、版本号或会话粘滞提升一致性记忆钩子：先定义问题，再说明一致性、可用性、分区、复制、时钟和故障模型的取舍；回答时要紧扣「一致性模型」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：一致性只有强一致和最终一致。 还有读己之写、单调读、因果一致、会话一致等中间模型。
- 误区：最终一致就是随便读旧数据。 最终一致要有收敛机制和时间窗口，不是无限期不一致。
- 误区：读写分离一定破坏业务。 可按业务选择读主、延迟双读、会话粘滞或接受短暂旧值。
- 追问：读己之写怎么实现？ 写后短时间读主库、携带版本号或把用户请求粘到同一副本。
- 追问：单调读解决什么？ 避免用户先读到新值、后读到旧值的倒退体验。
- 追问：如何向面试官举例？ 用主从复制延迟、订单状态和积分到账这类场景说明。
七、加强记忆
一致性模型是在回答“写完以后，谁在什么时候能读到什么版本”。强一致最稳但贵，最终一致便宜但要业务能接受短暂旧数据，中间还有读己之写、单调读、因果一致等折中。面试答题时按业务后果选择：钱、库存、权限偏强一致；点赞、浏览、搜索、缓存偏最终一致；用户体验用读己之写兜住。