结合多篇文章和实践，总结一下分布式事务相关的内容。
分布式事务是什么
百度百科的说法
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
分布式事务首先是一种事务，需要提供事务具有A（原子性）C（一致性）I（隔离性）D（持久性）四大特性。其次它是分布式的，涉及到多个不同子系统之间的交互，在这样复杂的情况下实现事务功能。
为什么需要分布式事务
需要在多个子系统交互完成一件事情的时候，如果不实现分布式事务，会导致事情完成情况出现各种不确定的因素，正常可能大部分都是成功，有一部分会出现失败和未知的情况，从而导致数据不一致。如果涉及到资金，可能会导致客户和公司产生巨大损失。因此需要分布式事务来保证数据的一致性。
分布式事务实现方式
分布式事务经过很长时间的演进，有很多种实现，每一种实现都有不同的使用场景。
2PC
2PC叫做两阶段提交，思路是事务参与者将操作成败通知事务协调者，再由事务协调者根据所有事务参与者的反馈情报决定各事务参与者是否要提交操作还是中止操作。
其中事务参与者也叫做资源管理器，事务协调者也叫做事务管理器。资源管理器（RM, resource manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, transaction manager）分 2 阶段协调所有资源管理器。
缺点
- 同步阻塞问题
- 协调者不可靠
3PC
3PC叫做三阶段提交，三阶段提交是对二阶段提交的改进。三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，使得原先在两阶段提交中，事务参与者在投票之后，由于事务协调者发生崩溃或错误，而导致事务参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
TCC
TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现， Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。
TCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。
要点
- 空回滚
- 防悬挂
- 幂等
基于消息队列的事务
前提条件就是，异步执行的那部分操作，不能有依赖的资源。比如说，我们下单的时候，除了要清空购物车以外，还需要锁定库存。
Saga
一个Saga事务就是一个长期运行的事务，这个事务是由多个本地事务所组成， 每个本地事务有相应的执行模块和补偿模块，当Saga事务中的任意一个本地事务出错了， 可以通过调用相关事务对应的补偿方法恢复，达到事务的最终一致性。
适用场景：
- 业务流程长、业务流程多
- 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口
优势：
- 一阶段提交本地事务，无锁，高性能
- 事件驱动架构，参与者可异步执行，高吞吐
- 补偿服务易于实现
缺点：
- 不保证隔离性
实践
Seata实践
Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
Seata的精华在于对业务的非侵入性，事务与业务分离，客户可以聚焦于业务开发。
性能方面，SEATA架构可以支撑10万tps以上。
高可用方面，任一节点故障可以做到秒级恢复。
TC (Transaction Coordinator) - 事务协调者负责维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器负责定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器负责管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata 与其它分布式最大的区别在于，它在第一提交阶段就已经将各个事务操作 commit 了。
Seata 认为在一个正常的业务下，各个服务提交事务的大概率是成功的，这种事务提交操作可以节约两个阶段持有锁的时间，从而提高整体的执行效率。
那如果在第一阶段就已经提交了事务，那我们还谈何回滚呢？
Seata 将 RM 提升到了服务层，通过 JDBC 数据源代理解析 SQL，把业务数据在更新前后的数据镜像组织成回滚日志，利用本地事务的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个本地事务中提交。如果 TC 决议要全局回滚，会通知 RM 进行回滚操作，通过 XID 找到对应的回滚日志记录，通过回滚记录生成反向更新 SQL，进行更新回滚操作。
以上我们可以保证一个事务的原子性和一致性，但隔离性如何保证呢？
Seata 设计通过事务协调器维护的全局写排它锁，来保证事务间的写隔离，而读写隔离级别则默认为未提交读的隔离级别。
具体实践可以查看下面Spring Cloud Alibaba集成的示例
https://github.com/alibaba/spring-cloud-alibaba/blob/master/spring-cloud-alibaba-examples/seata-example/readme-zh.md
TCC实践的业务流程图
国内开源TCC框架：ByteTCC，TCC-transaction，Himly
最佳实践和参考资料
- http://seata.io/zh-cn/blog/tcc-mode-design-principle.html
- https://www.cnblogs.com/jajian/p/10014145.html
- http://seata.io/zh-cn/blog/tcc-mode-applicable-scenario-analysis.html
这篇文章讲述了TCC事务实现方式在不同的业务场景下的适配性，根据场景谈实现方案真是最好的方式。
- http://servicecomb.incubator.apache.org/cn/docs/distributed-transactions-saga-implementation/
- https://time.geekbang.org/column/article/111269
- https://time.geekbang.org/column/article/127527
- https://coolshell.cn/articles/10910.html