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