高 困难
数据一致性方案#
一句话答案#
强一致用 2PC/XA（性能差），最终一致用事务消息/TCC/SAGA/本地消息表，根据业务场景权衡一致性和性能。
核心要点
| 方案 | 一致性 | 性能 | 侵入性 |
|---|---|---|---|
| 2PC/XA | 强 | 低 | 低 |
| TCC | 最终 | 高 | 高 |
| SAGA | 最终 | 高 | 中 |
| 消息表 | 最终 | 中 | 中 |
| 事务消息 | 最终 | 高 | 低(推荐) |
面试回答（2分钟版）
分布式数据一致性方案可以分为强一致和最终一致两大类。强一致方案主要是 2PC/XA，协调者统一控制所有参与者的提交和回滚，一致性好但性能差、存在阻塞问题，适合小范围的数据库事务。大部分互联网场景用最终一致性方案就够了，主要有四种：TCC 适合资金核心场景，Try 预留资源、Confirm 确认、Cancel 回滚，性能高但业务侵入大；SAGA 适合长流程编排，每步有对应的补偿操作，失败时逆序补偿；本地消息表是在业务数据库中额外维护一张消息表，通过定时任务轮询保证消息最终发出；事务消息是最推荐的方案，RocketMQ 原生支持半消息机制，先发半消息再执行本地事务，成功就 commit 失败就 rollback，Broker 还有回查机制兜底。选型原则是能异步不同步、能最终一致不强一致，最终都要靠对账机制做兜底保障。
追问与易错
追问方向：
- “最终一致能接受多久延迟？”→ 取决于业务 SLA：支付核心链路秒级（消息队列实时消费），积分/优惠券分钟级，报表统计可以小时级或日终对账
- “怎么选强一致还是最终一致？”→ 资金/库存等核心数据用强一致（2PC/TCC），用户昵称/积分/通知等非核心数据用最终一致（事务消息/SAGA），按业务分级
- “对账机制怎么设计？”→ 定时任务拉取时间窗口内各服务的数据比对状态，不一致的自动修复（可修复类型）或告警人工处理，核心链路 5 分钟对账，非核心日终对账
易错点：
- ❌ 分布式一定不能强一致——小范围可以
- ❌ 最终一致就是慢慢一致——需有明确补偿机制