01

60 秒回答模板

回答时先把一致性分层：副本之间的数据一致性、跨服务状态一致性、业务最终收敛。强一致场景通常用单 leader、WAL、多数派提交、Raft/Zab 等方式确定写入顺序；读路径要选择读 leader、Quorum 读或带版本的会话读，避免读到旧副本。允许最终一致的业务，要用 outbox/事务消息、幂等消费、重试、补偿、对账和告警，把超时、重复、乱序和分区后的状态拉回正确结果。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先定义一致性目标

不要直接说强一致。先问业务是否要求线性一致、读己之写、单调读，还是能接受秒级最终一致。资金、库存、权限变更通常更偏强一致；计数、动态、通知通常可以用最终一致换可用性和吞吐。

02

副本写入要有确定顺序

典型强一致写入链路是 leader 收到请求，先写 WAL，再复制到多数派副本，达到提交条件后推进 commit index，状态机 apply，最后返回客户端。这样即使少数节点故障，也能从日志恢复出同一顺序。

03

读路径同样要讲清楚

写入一致不代表读一定一致。读从库可能遇到复制延迟；读 leader 延迟更高但结果新；Quorum 读写可通过 `R + W > N` 提升读到最新版本的概率；会话一致要保存版本号或路由到能覆盖该版本的副本。

04

跨服务一致性靠状态收敛

微服务之间很难用一个本地事务解决所有修改。常见做法是本地事务写业务表和 outbox，再异步投递消息；消费者按业务唯一键幂等处理，失败进入重试、死信、补偿任务和定期对账。

05

故障场景决定方案强度

网络分区、leader 切换、请求超时、客户端重试都可能造成双写、旧读或重复执行。高质量回答要说明如何用多数派、任期、幂等键、状态机前置校验和人工兜底限制错误扩大。

03

易错点

  • 只背 CAP，不说明具体写入协议、读路径和异常恢复。
  • 把一致性等同于加锁，忽略副本日志、版本号和业务幂等。
  • 只讲写一致性，不讲读从延迟、读己之写和旧读问题。
  • 最终一致只说消息重试，不说死信、补偿、对账和告警。
04

面试官追问

强一致和最终一致怎么选？

看错误成本和可接受窗口。钱、库存、权限这类错误不可接受的状态要提高一致性；点赞数、通知、搜索索引可接受短暂延迟，更适合最终一致。

Quorum 为什么常说 `R + W > N`？

因为读集合和写集合必然有交集，读请求有机会读到最新写入的副本。但它还要配合版本比较、故障处理和正确的读修复，不能只记公式。

只靠重试能保证一致性吗？

不能。重试会放大重复执行风险，必须配合幂等键、唯一约束、状态机校验和可观测的补偿任务。

网络分区时怎么避免双写？

依赖多数派和任期约束，只有获得合法多数派的 leader 能提交；业务层还要用 fencing token 或版本号防止旧持有者继续写入。