分布式事务

分布式事务

假设情况 支付和配送也不在同一个系统中
支付成功的逻辑如下

1
2
3
4
支付成功结果通知{
将用户的订单状态改为支付成功
远程调用接口添加配送服务
}

假设是添加了@transaction这种事务回调方式
我们发生如下步骤

  1. 将用户订单状态改为支付成功success 但是 并没有commit
  2. 远程回调接口添加配送服务成功success 在订单服务中 已经commit了
  3. 进行commit的时候 改为支付成功这件事 失败了
    这就导致了事务的不一致

本地事务

  1. 一个关系型数据库来控制事务

分布式事务

  1. 多个系统协同来完成一个事务

CAP理论

  • C: consistency 强一致性 同一时候 系统的数据都是一致的 注意: 强一致性和最终一致性不一样
  • A: available 可用性
  • P: partition tolerance 分区容错性
  • C 就是说 假设有 a b c 三个系统, a b c 三个系统的数据要是一致的 这个一致性是强一致性,就是任何节点时刻 abc三个系统的数据都是一致的
  • A: 可用性, 就是 假设有abc三个系统 a挂了 b还能用
  • P: 服务 a 和 b 之间有时候会由于网络原因无法连接,这种情况下,我还要保证 abc这个组成的系统是可用的

  • 一般来说 假设分布式分布的系统越多,那么他的强一致性就越弱,

分布式事务的解决方案总结

1 两阶段提交(2PC)

(2 Phase Commitment Protocol),两阶段提交由 协调者和参与者组成,共经过两个阶段和三个操作

  1. 应用程序连接两个数据源。

  2. 应用程序通过事务协调器向两个库发起prepare,两个数据库收到消息分别执行本地事务(记录日志),但不提
    交,如果执行成功则回复yes,否则回复no。

  3. 事务协调器收到回复,只要有一方回复no则分别向参与者发起回滚事务,参与者开始回滚事务。

  4. 事务协调器收到回复,全部回复yes,此时向参与者发起提交事务。如果参与者有一方提交事务失败则由事务协 调器发起回滚事务。

2PC的优缺点:

  • 优点: 实现强一致性,部分关系数据库支持(Oracle、MySQL等)。

  • 缺点: 整个事务的执行需要由协调者在多个节点之间去协调,增加了事务的执行时间,性能低下。 解决方案有:springboot+Atomikos or Bitronix

2 TCC事务补偿

TCC事务补偿方案示意图