强一致、弱一致和最终一致有什么区别？
简化版
强一致要求写入成功后，后续读取立刻能看到最新值；弱一致不保证读到最新值；最终一致允许短时间不一致，但只要没有新的更新，系统最终会收敛到一致状态。分布式系统里通常会在一致性、可用性、性能之间做取舍。
详细版
三者可以这样理解：
| 一致性模型 | 读到什么 | 典型场景 |
|---|---|---|
| 强一致 | 写成功后立刻读到最新数据 | 金融余额、库存强校验、配置发布 |
| 弱一致 | 不保证读到最新数据 | DNS 缓存、部分状态同步 |
| 最终一致 | 短时间可能旧，最终会一致 | 订单状态同步、积分发放、搜索索引更新 |
强一致体验确定，但通常要牺牲可用性或性能，例如需要同步复制、多数派确认或分布式事务。最终一致性能和可用性更好，但要设计重试、补偿、幂等、对账和用户体验提示。
面试时要强调：一致性不是越强越好，应该根据业务后果选择。资金扣减、库存超卖更偏强一致；短信通知、积分、搜索索引通常可接受最终一致。
完整版教学
一、为什么分布式系统会有一致性问题
单机数据库里，一次写入完成后再读，通常很容易读到新值。但分布式系统里，数据可能分布在多个节点、多个服务、多个存储系统中。
例如支付成功后，要更新订单状态、增加积分、发送消息、同步搜索索引：
支付服务 -> 订单服务
支付服务 -> 积分服务
支付服务 -> 消息队列 -> 搜索服务这些动作不可能总在同一个本地事务里完成。网络可能超时，消息可能延迟，下游可能暂时不可用，所以系统会出现“某些地方已经新了，某些地方还是旧的”的状态。
一致性模型就是描述系统在这些情况下对外承诺什么。
二、强一致的含义和代价
强一致强调写入成功后的可见性。用户支付成功后，再查询订单，必须看到已支付；扣库存成功后，再查库存，不能还显示旧库存。
为了做到强一致，系统通常需要同步协调。例如写入多个副本时，要等待多数副本确认；跨资源更新时，要使用事务协议或把关键数据放在同一个事务边界里。
代价也很明显：
- 延迟更高，因为要等待更多节点确认。
- 可用性可能下降，因为部分节点不可用时系统可能拒绝写入。
- 实现复杂，容易引入锁、阻塞、协调开销。
所以强一致适合“错一次代价很高”的场景，不适合所有业务都强行使用。
三、弱一致和最终一致的区别
弱一致是不承诺什么时候一致。你读到旧数据是允许的，系统也不一定告诉你多久后能变新。
最终一致比弱一致多了一个承诺：如果没有新的写入，并且系统内部重试、同步、修复最终完成，所有副本或相关系统会收敛到同一个结果。
例如支付成功后积分晚几秒到账，这通常是最终一致。用户短时间看到积分没变，但过一会儿刷新会更新。如果积分长时间不到账，系统还会通过重试和补偿修复。
四、最终一致不是“随便不一致”
最终一致经常被误用。有些系统只是失败了没人管，却说自己是最终一致，这是不对的。
真正的最终一致必须有收敛机制：
| 机制 | 作用 |
|---|---|
| 可靠消息 | 保证变化事件能传递到下游 |
| 幂等消费 | 重复消息不会造成重复副作用 |
| 失败重试 | 临时失败后继续尝试 |
| 补偿任务 | 修复流程中断或异常状态 |
| 对账校验 | 发现长期不一致 |
没有这些机制，所谓最终一致只是“希望它以后会好”。
五、面试中如何做业务取舍
可以按业务后果判断一致性级别。
资金余额、订单支付状态、库存扣减这类核心数据，通常要更强一致或至少在关键写入链路上强约束。用户昵称同步到订单快照、搜索索引更新、消息通知、积分发放，则通常可以最终一致。
一个常见设计是：核心链路同步保证关键状态正确，非核心副作用异步最终一致。
支付成功 -> 同步更新支付单和订单关键状态
支付成功事件 -> 异步加积分、发通知、同步报表六、常见误区与追问
这道题要紧扣「强一致、弱一致、最终一致」本身回答，不能把它混成泛泛的数据一致性套话。面试官通常会追问“写入怎么确认、失败怎么补、旧数据怎么防、成本在哪里”，所以回答要覆盖一致性目标、写入顺序、消息投递、幂等、补偿、对账和读写体验。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 强一致要求读到最新写入，弱一致不承诺何时可见，最终一致承诺在无新写入后各副本最终收敛 | 不要停在名词解释 |
| 流程机制 | 客户端发起写入 -> 系统选择一致性级别 -> 副本按策略确认 -> 读请求命中某副本 -> 可能读新值或旧值 -> 后台复制最终收敛 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 三副本写入时若要求所有副本确认再返回更接近强一致；只写主副本后异步复制就是最终一致常见形式 | 一致性方案本质是在强一致成本、系统可用性、延迟和业务可接受的不一致窗口之间取舍 |
强一致、弱一致、最终一致 面试拆解：
1. 客户端发起写入
2. 系统选择一致性级别
3. 副本按策略确认
4. 读请求命中某副本
5. 可能读新值或旧值
6. 后台复制最终收敛记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「强一致、弱一致、最终一致」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：最终一致就是弱一致。 最终一致至少承诺无新更新后会收敛，弱一致不一定给收敛时间承诺。
- 误区：强一致一定最好。 强一致通常牺牲延迟、可用性和跨地域性能。
- 误区：缓存系统无法谈一致性。 缓存也有读写一致、过期、失效和最终收敛问题。
- 追问：CAP 和一致性模型关系？ 网络分区下必须在一致性和可用性之间做取舍，具体表现为不同一致性模型。
- 追问：什么时候用强一致？ 扣款、库存强校验、权限变更等不能容忍旧值的场景。
- 追问：什么时候用最终一致？ 搜索索引、缓存、通知、报表和可补偿的跨服务流程。
七、加强记忆
一致性选择看的是业务后果：强一致保证“写完立刻都看见”，但成本高；最终一致允许短暂旧数据，但必须有消息、重试、幂等、补偿、对账让系统最终收敛。不是越强越好，是该强的地方强，该异步的地方异步。