分布式事务解决方案

事务内的操作要么全部成功，要么全部失败，不会在中间的某个环节结束

Atomicity（原子性）

数据库在一个事务执行之前和执行之后，都必须处于一致性状态，事务提交或执行失败，看到的结果一致

Consistency（一致性）

并发环境中，不同事务同时修改相同数据时，一个未完成事务不会影响另外一个未完成事务

Isolation（隔离性）

事务一旦提交，其修改的数据将永久保存到数据库，改变是永久的

Durability（持久性）

ACID（更多指数据库事务层面）

数据库事务

所有节点每次读操作都能保证获取最新数据，且一致。

在集群中一部分节点故障后，集群整体还能响应客户端的读写请求，保证服务仍然可用

Availability（可用性）

网络节点之间无法通信的情况下， 节点被隔离，产生了网络分区， 整个系统仍然是可以工作的。简单理解，被分区的节点可用正常对外提供服务

Partition tolerance（分区容错性，是分布式的基础）

CAP理论

Basically Available（基本可用）

Soft state（软状态）

Eventually consistent（最终一致性）

BASE理论

分布式事务理论

1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复。

2、各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。

3、如参与者执行成功，给协调者反馈 yes，否则反馈 no。

阶段一（准备阶段）

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息。

阶段二（提交阶段）

 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。

可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。

数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。

存在的问题

尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

优点

实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

缺点

优缺点

传统XA

第一阶段commit并记录undo日志

第二阶段提交或者回滚

Seata

具体实现

两阶段提交（2PC）

1、协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。

2、参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

协调者根据参与者响应情况，所有参与者均反馈 yes，协调者预执行事务。只要有一个参与者反馈 no，或者等待超时后协调者尚无法收到所有提供者的反馈，即中断事务

阶段二（预提交阶段）

进行真正的事务提交

阶段三（提交阶段）

相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题。阶段 3 中协调者出现问题时，参与者会继续提交事务

数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

三阶段提交（3PC）

需要实现确认和补偿逻辑，支持幂等

条件

1、Try 阶段主要是对业务系统做检测及资源预留。完成所有业务检查( 一致性 ) 。预留必须业务资源( 准隔离性 ) 。Try 尝试执行业务。

2、Confirm 阶段主要是对业务系统做确认提交。Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

3、Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

处理流程

1、性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。

2、数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。

3、可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。

TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本

传统的关系型数据库使用这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java 里面的同步 synchronized 关键字的实现。悲观锁主要分为共享锁（读锁）和排他锁（写锁）

悲观锁

CAS 加版本号version，先查询再更新根据版本。使用条件限制实现乐观锁

乐观锁

通过悲观锁与乐观锁保证数据的唯一性，确保幂等性

幂等处理

空回滚

资源悬挂

异常处理

补偿事务（TCC）

本地表

消息队列

可靠消息最终一致性

拆分分布式事务为多个本地事务，由saga引擎负责协调，如果过程中出现部门失败，调用补偿操作。恢复策略：向前恢复和向后恢复，向前恢复对失败的节点采取最大努力不断重试，保证数据库的操作最终一定保证数据一致性，如果最终多次重试失败则根据相关日志主动通知开发人员手工介入。向后恢复对之前的成功节点执行回滚的事务操作，保证数据一致性。Saga比TCC少了Try操作，因此会直接提交数据库，然后出现失败进行补偿。

Sagas事务模型（最终一致性）

通知接收方监听发送方mq，但mq并非和可靠消息最终一致性一样，没有ack就会一直推，而是根据规则推几次就不推了。但提供反查接口

方案一

发送方通知程序监听自己队列，http协议发给消息接收方

方案二 

最大努力通知

解决方案

分布式事务