分布式事务严谨的定义：分布式环境下的事务处理机制
CAP定理：在一个分布式系统中，涉及共享数据问题时，以下三个特性最多只能同时满足两个
一致性：代表数据在任何时刻、任何分布式节点中看到的都是符合预期的，一致性概念在分布式研究中是有严肃定义和多种细分类型的概念（与分布式共识算法中的面向副本复制的一致性不同，此处指的是面向数据库状态的一致性）。
可用性：代表系统不间断的提供服务的能力，与其密切相关的两个指标为可用性和可维护性。可靠性使用平均无故障时间来度量，可维护性用平均可修复时间来度量
分区容忍性：代表分布式环境中部分节点因为网络原因而彼此失联后，即与其他节点形成“网络分区时”，系统仍能正确地提供服务的能力。
选择放弃一致性的AP系统是目前设计分布式系统的主流选择，因为：
1、P是分布式网络的天然属性（永远可靠的通信在分布式系统中必定不成立，这不是设计者想不想的问题，而是只要用到网络来共享数据，分区现象就会始终存在），目前条件下，无论如何设计也无法避免P的出现。
2、A是建设分布式系统的目的，如果可用性随着节点数量增加反而降低的话，很多分布式系统就失去了价值。除非是银行、证券这些涉及金钱交易的服务，宁可中断也不能出错，否则多数系统是不能容忍节点越多可用性反而越低的。
需要注意的是CAP和ACID理论中的一致性称为强一致性或者在线一致性。无论如何，我们建设信息系统终究还是要确保操作结果至少在最终交付的时候是正确的（解读：允许数据在中间过程中出错（不一致）， 但应该在输出时被修正过来）。因此在牺牲了C的AP系统中，要尽可能地获得正确的结果的行为称为追求“弱一致性”。在强一致性和弱一致性之间还存在着最终一致性：如果数据在一段时间内没有被另外的操作所更改，那么它最终会达到与强一致性过程相同的结果。面向最终一致性的算法也被称为“乐观复制算法”。
TCC分布式事务机制：TCC由“try-confirm-cancel”三个单词缩写而成。如同TCC名字所示，它分为如下三个过程：
1、Try：尝试执行阶段，完成所有业务可执行性的检查（保障一致性），并且预留好全部需要用到的业务资源（保障隔离性）；
2、Confirm阶段：确认执行阶段，不进行任何业务检查，直接使用Try阶段准备的资源来完成业务处理。Confirm阶段可能会重复执行（失败重试导致的），因此本阶段所执行的操作需要具备幂等性（即多次执行结果和执行一次的结果相同）；
3、Cancel阶段：取消执行阶段，释放Try阶段预留的业务资源。Cancel阶段也可能会重复执行，因此也需要满足幂等性。
TCC其实有点类似于2PC的准备阶段和提交阶段，但是TCC位于用户代码层面（即业务代码，写业务代码的程序员相对于基础库而言都是用户），而不是基础设施层面。
TCC业务侵入性和开发成本都很高，所以一般我们不会完全靠裸编码实现TCC，而是会借助一些分布式事务中间件去完成，尽可能地减轻编码工作量。
SAGA事务：TCC事务是常见柔性事务中性能最高的，但是它并不能满足所有场景，因此有了SAGA事务。SAGA事务的设计思路：把一个大事务分解，目的是为了避免大事务长时间锁定数据库的资源。 SAGA由两部分操作组成：
1、大事务拆分成若干个小事务，整个分布式事务T分解成n个子事务，命名为
，，…，，…，。每个子事务都应该是或者能被视为是原子行为。如果分布式事务能够正常提交，其对数据的影响（最终一致性）应与连续按顺序成功提交 等价。
2、为每个子事务设计一个对应的补偿动作，命名为。与需要满足如下条件：（1）与都具备幂等性；（2）与满足交换律，即无论是先执行还是，其效果都是一样的；（3）必须能成功提交，即不考虑本身提交失败回滚的情形，如出现本身提交失败，就必须持续重试直至成功或者人工介入。
如果到均成功提交，那么事务顺利完成，否则就需要采用正向恢复策略或者反向恢复策略。
正向恢复（Forward Recovery）： 如果事务提交失败，则一直对进行重试直到成功为止（最大努力交付），这种恢复方式不需要补偿，适用于事务最终都要成功的场景，正向恢复的执行模式为：（失败）,（重试）,。
反向恢复（Backward Recovery）:如果事务提交失败，则一直执行对进行补偿，直到成功为止（最大努力交付）。这里要求（可通过持续重试）必须执行成功。反向恢复的执行模式为：(失败),(补偿),。
SAGA必须保证所有子事务都得以提交或者补偿，但实际SAGA系统本身也有可能会崩溃，所以他必须被设计成数据库类似的日志机制以保证系统恢复后可以追踪到子事务的执行情况。例如直行道哪一步或者补偿到哪一步了。