分布式事务

概念：

分布式事物产生原因：主要产生与在微服务系统中，数据库的垂直拆分或者是RPC远程调用，不在同一个数据源中，而是多个数据源中，每个数据源的事物都是本地事物，互不影响。所以当A服务的数据源的事物发生回滚，不会影响到B服务的数据源回滚，从而产生分布式事物问题，无法保证分布式通讯数据一致性问题。

事务补偿机制:

• 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务.

CAP理论:

• CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统(zookeeper), AP系统(Eureka).

一致性(Consistency): 客户端知道一系列的操作都会同时发生(生效)

可用性(Availability): 每个操作都必须以可预期的响应结束

分区容错性(Partitiontolerance):

• 即使出现单个组件无法可用,操作依然可以完成
  幂等性: 简单的说, 业务操作支持重试, 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID.
  BASE(Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准.

柔性事务和刚性事务：

• 刚性事务满足ACID理论（例如单机环境下的数据库事务）
• 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 两阶段提交(2PC), TCC补偿型提交, 基于消息的异步确保型, 最大努力通知型。

分布式事物常见解决方案:
2pc：
将事务的提交过程分为：准备阶段和提交阶段。
阶段1：准备阶段

1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2、各参与者执行事务操作，但不提交事务。
3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。

阶段2：提交阶段

此阶段分两种情况：所有参与者均反馈YES、或任何一个参与者反馈NO。
所有参与者均反馈YES时，即提交事务。
任何一个参与者反馈NO时，即中断事务。

提交事务：（所有参与者均反馈YES）

1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。
2、参与者执行Commit请求，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。

中断事务：（任何一个参与者反馈NO）

1、协调者向所有参与者发出回滚请求（即Rollback请求）。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。

2PC的缺陷：

1、同步阻塞：最大的问题即同步阻塞，即：所有参与事务的逻辑均处于阻塞状态。
2、单点：协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态。
3、脑裂：在阶段2中，如果只有部分参与者接收并执行了Commit请求，会导致节点数据不一致。

3pc：
三阶段提交协议，是2PC的改进版本，即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。
阶段1：CanCommit

1、协调者向参与者发出CanCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2、参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈YES，否则反馈NO。

阶段2：PreCommit
事务预提交：（所有参与者均反馈YES时）

1、协调者向所有参与者发出PreCommit请求，进入准备阶段。
2、参与者收到PreCommit请求后，执行事务操作，但不提交事务。
3、各参与者向协调者反馈Ack响应或No响应，并等待最终指令。

中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）

1、协调者向所有参与者发出abort请求。
2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。

阶段3：do Commit
提交事务：（所有参与者均反馈Ack响应时）

1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
2、参与者收到do
Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。

中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）

1、如果协调者处于工作状态，向所有参与者发出abort请求。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。

3PC的优点和缺陷：
优点：降低了阻塞范围，引入了超时机制，在等待超时后协调者或参与者会中断事务。
缺陷：脑裂问题依然存在，即在参与者收到PreCommit请求后等待最终指令，如果此时协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

TCC：
是基于补偿型事务的AP系统的一种实现, 具有最终一致性.
Try:

完成所有的业务检查(一致性),预留必须业务资源(准隔离性);
体现在本例中, 就是确认客户账户余额足够支付(一致性), 锁住客户账户, 商户账户(准隔离性).

Confirm:

使用Try阶段预留的业务资源执行业务(业务操作必须是幂等的), 如果执行出现异常, 要进行重试. 在这里就是执行客户账户扣款, 商户账户入账操作.

Cancle:

释放Try阶段预留的业务资源, 在这里就是释放客户账户和商户账户的锁; 如果任一子业务在Confirm阶段有操作无法执行成功, 会造成对业务活动管理器的响应超时, 此时要对其他业务执行补偿性事务. 如果补偿操作执行也出现异常, 必须进行重试, 若实在无法执行成功, 则事务管理器必须能够感知到失败的操作, 进行log(用于事后人工进行补偿性事务操作或者交由中间件接管在之后进行补偿性事务操作).

优点：

1、TCC能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放, 例如, 假设有AB两个操作, 假设A操作耗时短, 那么A就能较快的完成自身的try-confirm-cancel流程, 释放资源. 无需等待B操作. 如果事后出现问题,
追加执行补偿性事务即可.
2、TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作), 也就是各服务之间可以在一定程度上”异步并行”执行.

注意事项：

事务管理器(协调器)这个节点必须以带同步复制语义的高可用集群(HAC)方式部署.
事务管理器(协调器)还需要使用多数派算法来避免集群发生脑裂问题.

适用场景：

严格一致性 执行时间短 实时性要求高 （举例: 红包, 收付款业务.）

消息中间件最终一致性：

通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响。这个方案真正实现了两个服务的解耦, 解耦的关键就是异步消息和补偿性事务。

执行步骤如下:

1.MQ发送方发送远程事务消息到MQ Server;
2.MQ Server给予响应, 表明事务消息已成功到达MQ Server.
3.MQ发送方Commit本地事务.
4.若本地事务Commit成功, 则通知MQ Server允许对应事务消息被消费; 若本地事务失败, 则通知MQ Server对应事务消息应被丢弃.
5.若MQ发送方超时未对MQ Server作出本地事务执行状态的反馈, 那么需要MQ Server向MQ发送方主动回查事务状态, 以决定事务消息是否能被消费.
6.当得知本地事务执行成功时, MQ Server允许MQ订阅方消费本条事务消息.

需要额外说明的一点, 就是事务消息投递到MQ订阅方后, 并不一定能够成功执行. 需要MQ订阅方主动给予消费反馈(ack);如果MQ订阅方执行远程事务成功, 则给予消费成功的ack, 那么MQ Server可以安全将事务消息移除;如果执行失败, MQ Server需要对消息重新投递, 直至消费成功.