分布式事务模型
- TCC 模型：TCC-Transaction、Hmily
- XA 模型：Sharding Sphere、MyCAT
- 2PC 模型：raincat、lcn
- MQ 模型：RocketMQ
- BED 模型：Sharding Sphere
- Saga 模型：ServiceComb Saga
TCC
TCC事务解决方案本质上是一种补偿的思路，它把事务运行过程分成try、confirm/cancel 两个阶段，每个阶段都由业务代码来控制。需要注意的是，TCC事务和2pc的思想类似，但与2pc实现不同，TCC不再是两阶段提交，而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑。
实现过程：
-
try：完成所有业务检查（一致性），预留业务资源。
-
confirm：确认执行业务操作，只使用try阶段预留的业务资源。
-
cancel：取消try阶段预留的业务资源。
XA模型（规范）
xa是个规范，根据这个思想衍生二阶段提交协议和三阶段提交协议。
XA分布式事务是由一个或者多个Resource Managerd，一个事务管理器Transaction Manager以及一个应用程序 Application Program组成。
-
资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器。
-
事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务中的资源管理器进行通信。
-
应用程序：定义事务的边界，指定全局事务中的操作。
2pc
二阶段提交是分布式事务的重要的一个关键点，二阶段提交协议包含了两个阶段：第一阶段（也称准备阶段）和第二阶段（也称提交阶段）。
引用《Java事务设计策略》一图
-
准备阶段：准备阶段，每个资源管理器都会被轮训一遍，事务管理器给每个资源管理器发送Prepare消息，每个资源管理器要么直接返回失败(如权限验证失败)或异常，要么在本地执行事务等等，但不Commoit，处于Ready状态。
-
提交阶段：如果事务管理器收到了资源管理器的失败信息(如异常、超时等)，直接给每个资源管理器发送回滚(Rollback)消息；否则，发送提交(Commit)消息；资源管理器根据事务管理器的指令执行Commit或者Rollback操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
可以看出，二阶段提交这么做的就是让前面都完成了准备工作，才能提交整个事务，若中间由某一环节出现问题，则整个事务回滚。
从两阶段提交的工作方式来看，很显然，在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，这样，比起一阶段提交，两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。
MQ模型
消息一致性方案是通过消息中间件保证上下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，下游应用向消息系统订阅该消息，收到消息后执行相应操作。本质上是依靠消息的重试机制，达到最终一致性。消息驱动的缺点是：耦合度高，需要在业务系统中引入MQ，导致系统复杂度增加。
bed模型（柔性事务）
柔性事务是对XA协议的妥协和补偿，它通过对强一致性要求的降低，已达到降低数据库资源锁定时间的效果。柔性事务的种类很多，可以通过各种不同的策略来权衡使用。
一阶段提交 + 补偿 ：最大努力送达（BED）
最大努力送达，是针对于弱XA的一种补偿策略。它采用事务表记录所有的事务操作SQL，如果子事务提交成功，将会删除事务日志；如果执行失败，则会按照配置的重试次数，尝试再次提交，即最大努力的进行提交，尽量保证数据的一致性，这里可以根据不同的业务场景，平衡C和A，采用同步重试或异步重试。
这种策略的优点是无锁定资源时间，性能损耗小。缺点是尝试多次提交失败后，无法回滚，它仅适用于事务最终一定能够成功的业务场景。因此BED是通过事务回滚功能上的妥协，来换取性能的提升。
sagas事务模型
Saga事务模型又叫做长时间运行的事务（Long-running-transaction）, 它是由普林斯顿大学的H.Garcia-Molina等人提出，它描述的是另外一种在没有两阶段提交的的情况下解决分布式系统中复杂的业务事务问题。你可以在这里看到 Sagas 相关论文。
我们这里说的是一种基于 Sagas 机制的工作流事务模型，这个模型的相关理论目前来说还是比较新的，以至于百度上几乎没有什么相关资料。
该模型其核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务，然后由 Sagas 工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。
比如我们一次关于购买旅游套餐业务操作涉及到三个操作，他们分别是预定车辆，预定宾馆，预定机票，他们分别属于三个不同的远程接口。可能从我们程序的角度来说他们不属于一个事务，但是从业务角度来说是属于同一个事务的。
他们的执行顺序如上图所示，所以当发生失败时，会依次进行取消的补偿操作。
因为长事务被拆分了很多个业务流，所以 Sagas 事务模型最重要的一个部件就是工作流或者你也可以叫流程管理器（Process Manager），工作流引擎和Process Manager虽然不是同一个东西，但是在这里，他们的职责是相同的。在选择工作流引擎之后，最终的代码也许看起来是这样的
链接
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
https://yq.aliyun.com/articles/621241
来源：oschina
链接：https://my.oschina.net/u/3421984/blog/3009142