大白话讲明白什么是分布式事务？

分布式事务？什么东西？分布式我听过，事务我也听说，分布式事务是什么鬼？相信兄弟萌初次听说分布式事务跟我一样，一脸懵逼！不多 BB，进入正题…

要想搞懂分布式事务，首先解决两个问题：什么是分布式系统？什么是事务？

简单来说，分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的多个计算机节点组成的系统
简单来说，事务就是作为单个逻辑单元执行的一组操作，要么全部成功，要么全部失败

分布式事务顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。

假如没有分布式事务会怎么样？

我们以电商系统中的下单扣库存为例，电商系统中，订单系统和库存系统是两个系统，一次下单操作由两个系统协同完成。

在交易系统的业务逻辑中，一个商品在下单之前需要先调用库存服务，进行扣除库存，再调用订单服务，创建订单记录。正常情况下，两个数据库各自更新成功，两边数据维持着一致性。

但是，可能由于网络或其它原因，导致库存扣减完成，但订单记录却插入失败，结果是库存减少了，却没有相应的订单。这时两边数据就失去了应有的一致性。

这种时候必须要保证数据的一致性。单数据源的一致性依靠单机事务来保证，多数据源的一致性就要依靠 【分布式事务】。

如何实现分布式事务？

分布式事务可简单理解为涉及多个数据库的事务，要同时更新几个不同的数据库，难点在于数据库在物理机器上是独立的，一个数据库在执行本地事务时不知道其它机器数据库事务执行情况。为了保持所有的执行一致，需要引入事务协调者，由协调者来统一管理参与的多个数据库执行情况。

分布式事务的实现有很多种，最具有代表性的是由 Oracle Tuxedo 系统提出的 XA 分布式事务协议。

XA 协议包括：两阶段提交（2PC）和三阶段提交（3PC）两种实现。

两阶段提交（2PC）

• 准备阶段
  协调者向所有参与者发出准备提交信息，如果参与者本地事务操作成功（执行事务但不提交），则返回准备好了，如果参与者本地事务操作失败，则返回失败。

• 提交阶段
  如果协调者收到了所有参与者回复成功的消息，则向每个参与者发送提交消息，否则发送回滚消息。参与者根据协调者的指令执行提交或者回滚本地事务操作，释放所有事务处理过程中使用的锁资源。
  

两阶段提交存在的缺点：

1. 协调者可能存在单点故障
2. 数据可能存在不一致
   当所有参与者操作执行完成并向协调者发回同意的消息后，协调者向所有的参与者发出提交的请求，假设提交请求到达了参与者 1、参与者 2，但当提交请求发往参与者 3 时出现了网络异常，提交请求并没有到达参与者 3，就会出现参与者 1、参与者 2 提交了，但参与者 3 还没有提交，这时候整个分布式系统就可能会出现数据不一致的情况。

三阶段提交（3PC）

• 预备阶段
  协调者询问参与者是否可以执行事务提交操作，如果参与者自身认为可以顺利执行事务，则返回 YES 响应，否则返回 NO 响应
• 准备阶段
  与 2PC 的第一阶段类似，只不过这里协调者和参与者都引入了超时机制
• 提交阶段
  与 2PC 的第二阶段类似

三阶段提交有两个改动点：

1. 协调者和参与者同时引入了超时机制，而 2PC 只有协调者才拥有超时机制，避免了由于协调者宕机，参与者无法收到参与者反馈，会陷入阻塞情况，参与者自身拥有超时机制，它会在超时后自动进行本地 commit 从而进行释放资源
2. 插入一个预备阶段，询问用来保证数据是否可达

三阶段提交存在的缺点：

如果参与者 1 执行本地事务异常，返回一个终止消息给协调者，这时恰巧协调者也异常，协调者无法终止分布式事务，就会出现参与者 2 和参与者 3 由于超时机制提交了本地事务，但参与者 1 执行情况有异常，导致整个分布式系统的数据不一致。因此，三阶段提交虽然改进了二阶段提交的问题，但没有完美实现分布式事务。

具体实现中，我们会根据业务对数据进行补偿和修正，以保证业务的数据最终一致。

TCC 补偿机制

TCC 是业务层面的分布式事务，简单来说就是由业务开发程序员来保证分布式事务

TCC 由三个英文单词的首字母缩写而来，TCC 分别对应 Try、Confirm 和 Cancel 三种操作，这三种操作的业务含义如下：

• Try：预留业务资源，可简单理解成尝试执行业务，对业务系统做检测及资源预留
• Confirm：确认执行业务操作，只要 Try 成功，默认 Confirm 阶段不会出错
• Cancel：取消执行业务操作，业务执行错误需要回滚情况下执行