-
前言
- 为什么分布式系统最难保证的是“数据一致性”
- 举例：订单系统扣库存、支付系统异步通知、积分系统延迟更新
- 本文目标：梳理从本地事务到分布式一致性的完整演进路径
-
单体系统中的事务一致性
- ACID 原则回顾
- 数据库事务隔离级别对比（READ COMMITTED / REPEATABLE READ / SERIALIZABLE）
- 常见问题：脏读、幻读、丢失更新
-
分布式系统中的一致性问题
- 跨库 / 跨服务操作为什么不能直接用事务？
- CAP 与 BASE 理论浅析
- 一致性分类：强一致性、弱一致性、最终一致性
-
常见分布式一致性方案
-
2PC / XA 协议：理论完美，工程中难落地
-
TCC 模型：Try-Confirm-Cancel，适合核心业务（如支付）
-
消息事务（Outbox + MQ） ：
- 本地事务 + MQ 异步事件
- 幂等消费保障最终一致性
-
SAGA 模型：补偿事务链式回滚
-
-
实战案例：订单创建 + 库存扣减
- 方案一：本地事务 + RocketMQ 消息通知
- 方案二：TCC 模式下的库存冻结
- 幂等控制 + 重试机制
-
工程实践建议
- 幂等设计的通用思路（业务唯一 ID）
- 状态机表驱动：记录每个事务步骤
- 分布式事务框架选型：Seata / LCN / ByteTCC
-
总结
- 一致性没有银弹
- 关键是权衡“性能、可靠性、复杂度”
- 最佳实践：核心链路用强一致性，非核心用最终一致性
