分布式事务解析-CSDN博客

本文链接：https://blog.csdn.net/wzEminem/article/details/101079784

本文深入探讨分布式事务的必要性，分析2PC、TCC及消息事务的特点与应用场景，对比其优劣，阐述微服务架构下如何解决跨服务数据一致性问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

为什么有分布式事务

由于业务数据量非常巨大，如淘宝电商系统，后端肯定是分库分表的。因为单个数据库数据量压上来，系统就会产生性能瓶颈。库存和订单分别在不同数据库中。交易系统、库存系统、订单系统。【微服务架构中，像淘宝光一个下单链路可能会涉及10多个系统以上】如果下订单失败库存系统必须回滚数据，保证数据强一致性。
分布式事务种类
- 数据库的2PC（两阶段提交）又叫做 XA Transactions，强一致性、性能不高
- 补偿事务（TCC），记住3个单词 try、confirm、cancel，逻辑简单
- 消息事务，最终一致性，性能好
2PC（两阶段提交）：2阶段提交是分布式事务传统解决方案，目测银行保险都喜欢用这个。
- 当事务跨越多个节点时，为了保持事务ACID，引入了协调者、参与者
  - 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
  - 第二阶段：事务协调器要求每个数据库提交数据。
- 缺点：2PC效率很低，对高并发很不友好
  - 两阶段提交涉及多次节点的网络通信，导致通信时间过长。
  - 非常容易造成长事务，锁定资源时间太长，资源等待时间增多。
  - 大部分高并发场景都应该避免使用。
补偿事务TCC
- Try 阶段，对业务系统做检测和资源预留
- Confirm 阶段对业务系统做确认提交，默认：Try执行成功，Confirm一定成功
- Cancel 阶段在业务执行失败，需要回滚的情况下执行的业务取消，预留资源释放。
- 举例
  - Try 减库存
  - Confirm 更新订单
  - 如果更新订单失败，就进入Cancel阶段恢复库存，回滚阶段是业务编码来实现的（一个sql把库存更新回去）,不同业务场景需要不同的补偿代码，复用性差。
  - 缺点：对应用侵入性强、实现难度大
  - 优点：降低锁冲突、提高吞吐量成为可能，灵活自定义数据库操作的粒度
消息事务
- 思路：将本地事务和消息中间件放在一个事务中。保证最终一致性，过程不能保证
- 将分布式事务转换为两个本地事务
- 然后依靠下游业务的重试机制达到最终一致性
- 缺点：基于消息的最终一致性方案应用对应用侵入性高，需要大量业务改造成本高
- 分布式事务异常情况下面这些异常，都需要考虑
  - 机器宕机
  - 网络超时
  - 消息丢失
  - 数据错误
  - 消息乱序
  - 存储数据丢失
  - 失败消息重试

分布式事务处理机制