分布式事务为什么难
在微服务架构中，一个业务操作往往横跨多个服务，每个服务拥有自己的数据库。传统的ACID事务在分布式环境下难以直接应用，我们需要转向最终一致性模型。
一、理论基础：CAP与BASE
根据CAP定理，分布式系统无法同时满足一致性、可用性和分区容忍性。在微服务场景中，我们通常选择可用性，通过BASE理论（基本可用、软状态、最终一致性）来实现业务目标。
二、Saga模式详解
Saga模式将一个长事务拆分为多个本地事务，每个本地事务都有对应的补偿操作。分为两种实现方式：
- 编排式（Choreography）：各服务通过事件驱动的方式协作，服务之间通过消息传递触发下一步操作或补偿。
- 协调式（Orchestration）：由中央协调器（Orchestrator）统一调度，决定执行顺序和补偿逻辑。
三、TCC模式实战
TCC（Try-Confirm-Cancel）将每个操作分为三个阶段：
- Try：预留资源，检查业务约束
- Confirm：确认执行，真正扣减资源
- Cancel：取消执行，释放预留资源
实践要点：TCC要求Confirm和Cancel操作必须幂等，因为框架可能重试。此外，Try阶段不允许出现业务异常只允许出现技术异常。
四、本地消息表方案
在业务数据库中增加消息表，利用本地事务保证业务操作和消息写入的原子性。后台任务异步将消息投递到MQ。这是最轻量的最终一致性方案。
五、架构选型建议
| 方案 | 一致性 | 性能 | 复杂度 |
|---|---|---|---|
| Saga协调式 | 最终致 | 高 | 中等 |
| Saga编排式 | 最终致 | 高 | 低 |
| TCC | 强一致 | 中等 | 高 |
| 本地消息表 | 最终致 | 最高 | 低 |
发表评论 取消回复