如何设计最终一致性方案？
简化版
最终一致性方案通常通过本地事务保存业务数据和待发送事件，再用可靠消息通知下游，下游幂等消费，失败自动重试，长期异常通过补偿任务和对账修复。核心是让系统即使中间失败，也能持续向正确状态收敛。
详细版
一个完整的最终一致方案通常包含：
- 本地事务：先保证本服务核心数据正确。
- 事件记录：把需要通知下游的事件可靠保存。
- 消息投递：把事件发送到 MQ 或事件总线。
- 幂等消费：下游重复收到消息不会重复处理。
- 失败重试：发送失败、消费失败都要重试。
- 补偿任务：扫描异常状态进行修复。
- 对账机制：定期比对上下游数据，发现长期不一致。
例如支付成功后订单状态同步、积分增加、通知发送，可以让支付服务先提交支付成功，再发送支付成功事件；订单、积分、通知服务分别消费并保证幂等。
完整版教学
一、最终一致性方案的目标
最终一致不是要求所有系统同时成功，而是要求系统在失败、重试、延迟之后能收敛到正确状态。
以支付成功后加积分为例，支付结果必须先准确落库；积分可以晚几秒到账，但不能永久丢失，也不能重复增加。
这类场景不适合把支付和积分放进一个大分布式事务，因为积分不是支付成功的必要条件。更好的设计是支付成功作为事实事件，下游围绕这个事件最终完成自己的动作。
二、本地事务先保证核心事实
最终一致的第一步是让核心事实可靠落地。
例如支付服务在本地事务里做两件事：
更新支付单状态 = SUCCESS
写入待发送事件 = PaymentSucceeded这两件事必须在同一个本地事务内完成。否则可能出现支付成功了但事件没记录，后续下游永远不知道。
这就是 Outbox 思路的基础：业务数据和事件记录同库事务提交。
三、事件如何可靠投递
事务提交后，可以由后台线程或独立任务扫描待发送事件，把事件投递到消息队列。投递成功后把事件状态改成已发送。
如果投递失败，事件仍在表里，下次继续重试。这样即使应用发消息时宕机，也不会丢事件。
流程是：
业务事务提交 -> outbox 表有事件
投递任务扫描 -> 发送 MQ
发送成功 -> 标记已发送
发送失败 -> 保留待重试四、下游消费必须幂等
消息系统常见语义是至少一次投递，也就是消息可能重复。下游必须用业务唯一键去重。
例如积分服务消费 PaymentSucceeded：
唯一键：payment_id + points_type
如果已处理：直接返回成功
如果未处理：增加积分并记录处理流水这样即使同一支付成功事件被投递两次，也不会加两次积分。
五、补偿和对账负责兜底
可靠消息和重试能解决大多数问题，但仍然要承认系统可能存在长期异常。比如消息堆积、消费逻辑 bug、人工修数据、历史事件格式错误。
所以关键业务要有补偿和对账。补偿任务扫描支付成功但积分未到账的记录，重新触发积分处理；对账任务定期比对支付、订单、积分之间的状态差异。
补偿和对账是最终一致真正落地的最后防线。
六、最终一致的用户体验设计
最终一致还要让用户理解“正在处理”。比如支付成功后积分未立即到账，页面可以显示“积分预计几分钟内到账”，而不是让用户看到一个像失败的空状态。
查询接口也要区分主状态和派生状态。订单支付成功是主状态，积分、通知、报表是派生结果。主状态必须尽快准确，派生状态可以异步完成，并提供刷新、进度或异常提示。
后台系统则要给运营和客服提供查询入口：某笔订单的事件是否发出、下游是否消费、失败原因是什么、是否已进入补偿。否则最终一致出了问题，只能靠人工翻日志。
七、常见误区与追问
这道题要紧扣「最终一致性设计」本身回答，不能把它混成泛泛的数据一致性套话。面试官通常会追问“写入怎么确认、失败怎么补、旧数据怎么防、成本在哪里”，所以回答要覆盖一致性目标、写入顺序、消息投递、幂等、补偿、对账和读写体验。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 最终一致性允许短暂不一致，通过消息、重试、幂等、补偿、对账和状态机让系统最终收敛 | 不要停在名词解释 |
| 流程机制 | 定义一致性边界 -> 写入主状态 -> 发送事件通知 -> 下游幂等处理 -> 失败重试补偿 -> 对账确认收敛 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 订单支付后库存可能延迟 2 秒更新，只要页面状态、补偿和对账能保证最终正确，就属于可控最终一致 | 一致性方案本质是在强一致成本、系统可用性、延迟和业务可接受的不一致窗口之间取舍 |
最终一致性设计 面试拆解：
1. 定义一致性边界
2. 写入主状态
3. 发送事件通知
4. 下游幂等处理
5. 失败重试补偿
6. 对账确认收敛记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「最终一致性设计」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：最终一致就是随便不一致。 必须有明确的不一致窗口、收敛机制和可观测性。
- 误区：最终一致不需要事务。 每个本地步骤仍需要本地事务保护自己的状态。
- 误区：消息成功发送就代表最终一致完成。 还要保证消费成功、幂等、补偿和对账。
- 追问：怎么定义不一致窗口？ 按业务容忍度明确秒级、分钟级或人工处理级别。
- 追问：最终一致常见组件？ 消息队列、本地消息表、状态机、重试任务、补偿任务和对账系统。
- 追问：用户体验怎么处理？ 展示处理中状态、读主库、轮询结果或异步通知。
八、加强记忆
最终一致性的骨架是“本地事务记录事实和事件，可靠投递事件，下游幂等消费，失败自动重试，长期异常补偿和对账”。只说异步消息不够，必须讲清系统如何从失败中收敛。