分布式事务指事务的参与者, 支持事务的服务器, 资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.

简单的说, 就是一次大的操作由不同的小操作组成, 这些小的操作分布在不同的服务器上, 且属于不同的应用, 分布式事务需要保证这些小操作要么全部成功, 要么全部失败.

1. CAP

CAP 是指以下 3 个属性:

一致性 Consistency
数据的一致性
可用性 Availability
服务的可用性
分区容忍性 Partition tolerance
在网络异常的情况下, 服务能容忍网络分区之间的数据不一致时

CAP 理论指出分布式系统无法同时支持以上 3 个属性, 最多只能保证支持 2 个属性.

对于分布式系统, 必然要支持分区容忍性, 设计者需要在一致性与可用性之间权衡.

2. BASE

BASE 就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案, 也称柔性事务.

BASE是下面三个术语的缩写:

基本可用 Basically Available
分布式系统在出现故障时, 允许损失部分可用功能, 保证核心功能可用.
软状态 Soft state
允许系统中存在中间状态, 这个状态不影响系统可用性, 这里指的是 CAP 中的不一致.
最终一致 Eventually consistency
最终一致是指经过一段时间后, 所有节点数据都将会达到一致.

BASE 理论的核心思想是: 即使无法做到强一致性, 但每个应用都可以根据自身业务特点, 采用适当的方式来使系统达到最终一致性.
它完全不同于 ACID 的强一致性模型, 而是通过牺牲强一致性来获得可用性, 并允许数据在一段时间内是不一致的, 但最终达到一致状态.
但同时, 在实际的分布式场景中, 不同业务单元和组件对数据一致性的要求是不同的, 因此在具体的分布式系统架构设计过程中, ACID 特性和 BASE 理论往往又会结合在一起.

3. XA

XA 由 X/Open 组织提出的处理分布式事务的规范.
XA 规范能够允许在一个全局事务中协调多个分散的事务资源.
使用全局事务的应用会有一个或多个资源管理器和一个事务管理器.

资源管理器 Resource Manager
用于管理事务资源. 数据库服务就是一个资源管理器. 资源管理还应该具有管理事务提交或回滚的能力.
事务管理器 Transaction Manager
事务管理器是分布式事务的核心管理者. 事务管理器与每个资源管理器进行通信, 协调并完成事务的处理. 事务的各个分支由唯一命名进行标识.

3.1. 2PC

2PC, 二阶段提交, 2 Phase-Commit

XA 通常采用 2PC.

阶段一为准备(prepare)阶段.
即所有的参与者准备执行事务并锁住需要的资源.
参与者ready时, 向transaction manager报告已准备就绪.

阶段二为提交阶段(commit).
当transaction manager确认所有参与者都ready后, 向所有参与者发送commit命令.

3.2. 3PC

3PC, 三阶段提交

3.3. XA

XA, 是 2PC 的一种实现方式

4. TCC

补偿性事务, Try-Commit-Cancel

5. Paxos

6. 其他

异步处理
幂等失败, 成功, 处理中
分布式锁
乐观锁
MQ

http://www.tianshouzhi.com/api/tutorials/distributed_transaction/

JTA/XA

7. 思考

解决分布式事务

7.1. 1. 重试

在分布式事务处理中要允许重试, 所以要让事务中的每个操作操作幂等.

对于那些无法将操作转化为幂等操作的, 则无法解决分布式事务的一致性问题.
如 Reids 的 incr() 操作, 再不使用另外一个变量记录操作步骤的情况下, 就无法得知有没有重复操作过

8. Resource

MySQL XA MySQL XA SQL 语法 DTP 参考模型 DTP XA规范

https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
https://www.jianshu.com/p/16b1baf015e8