在当下随着系统规模变得越来越大，分布式的处理方式越来越受到业界的亲睐，大多数系统正在从集中式向分布式架构的变革，在分布式系统中，系统部署在不同的节点、数据分散在不同的数据库中，如果对这些数据进行分布式的事务处理具体非常大的挑战，分布事环境中，我们可以碰到
通信异常、网络分区、节点故障等故障，虽然存在着各种问题，但是在分布式领域，为了保证分布应用的可靠性，而分式式事务是无法回避的。
分布式事务
在一个分布式应用中，一个业务操作由多个分式的操作序列（子事务）组成，如何使多个子事务能够保证ACID的特性就是分布式事务。
分布式中的经典理论
CAP
(A)可用性：在分布式系统，如果想得到可用性，我们就是不允许数据有单点问题、应用存在单点故障，所以在分布式系统中数据副本、应用集群是保证可用性的关键，它给分布式系统带来 的巨大好处是不言而喻的
(C)一致性：在存在多个数据副本情况下，多个副本之间数据如何保证一致
(P)分区容错性：分布式系统所在的网络如果我们认为是一个大网络，网络分区就是这个大网络被划分成了多个子网络，而在多个子网络之前因为网络故障是无法互相通信的，这就是网络分区
在出现网络分区时候，如果不是整个网络出现故障，分布式系统仍然需要保证对外提供满足一致性和可用性的服务，这就需要系统在可用性和一致性之间做出一个权衡
要保证一致性，就需要将不一致的应用踢掉，停止提供服务，等数据同步之后再继续对外提供应用，这就会导致可用性的下降
要保证可用性，就要接受出现数据不一致的情况
在分布式系统中,系统中的组件必然会被部署在不同的机房、网络，否则就无所谓分布式了，所以分区是一个无法避免的问题，根据CAP理论，我们应该在C和A之间寻求平衡
BASE
基本可用（Basically Available）: 是在出现故障时，允许以一种有损的架构方式，继续对外提供服务，保证核心业务可用，有损可以体现在很多方面，比如损失响应时间、功能上的缺失、降级托底数据等
软状态（Soft State)：软状态对应的就是硬状态，是指允许系统中的数据存在不影响系统整体可用性的中间状态，业务上的软状态以付款为例，付款状态分为已付款、未付款，软状态是允许存在一种付款中的状态
最终一致（Eventually consistent）：强调系统中所有的数据，在经过时间周期T的同步后， 最终一定可以达到一致的状态，不要求实时保证强一致性。
如何保证分布式下的一致性
2PC（两阶段提交）
2PC是Two-Phase-Commit的缩写，即两阶段提交。2PC被认为是一种一致协议,该协议将事务分为两个阶段，角色分为，协调者和参与者,二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此也可以将二阶段提交看作一个强一致性的算法，
阶段1：提交事务请求
- 事务询问：协议者向所有参与发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应
- 执行事务：各参与者节点执行事务操作，并将undo和redo信息记录事务日志中，在这步已经锁定事务资源
- 各参与者向协调者反馈事务询问的响应：如果参与者执行事务成功，就返回YES给协调者，标识事务可以执行，如果参者执行事务失败，则反馈NO给协调者，标识事务执行失败
阶段2：执行事务提交
在该阶段协调者会根据各参与者的反馈情况，来决定如何处理该分布式事务
情况一：收到的反馈都是YES执行事务提交
- 发送提交请求
协调者向所有参与者节点发出 Commit 请求。
2 ．事务提交。参与者接收到 Commit 请求后，会正式执行事务提交操作，井在完成提交之后释放在整个事务执行期间占用的事务资源。
3 ．反馈事务提交结果。参与者在完成事务提交之后，向协调者发送 Ack 消息。
4 ．完成事务。协调者接收到所有参与者反馈的 Ack 消息后，完成事务。
情况二：收到的反馈中包含NO或者在等待超时之后,中断事务
发送回滚请求。协调者向所有参与者节点发出Rollback 请求。
2 ．事务回滚。参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3 ．反馈事务回滚结果。参与者在完成事务回滚之后，向协调者发送 Ack 消息。
4 ．中断事务。协调者接收到所有参与者反馈的 Ack 消息后，完成事务中断。
2pc缺点
同步阻塞
在阶段1的第二步，已经将事务资源锁定，一致到阶段2参与者在等待其它参与 者响应的过程中，得了处于一个阻塞状态，无法进行其它任何操作。极大限制了系统的性能
协调者单点问题
协调者在整个分布式事务中处于一个关键位置 ，如果协调者在第二阶段出现问题会导致事务无法完成，被锁定的事务资源将永远无法释放，
数据不一致
协调者在向所有参与者发出Commit请求后或在发送请求前崩溃，导致只有部分参与者收到Commit请求然后进行事务提交，未收到请求的则在自身等待超时之后中断事务，就会导致整个分布式系统中出现数据不一致的情况
太过保守，容错机制缺陷
在参与者与协调者失联的情况下， 协调者依靠自身的超时机制来决定是否中断事务，这种策略比较保守，没有一个比较完善的容错机制，任意一个节点的失败都会导致整个事务的失败。
3PC(三阶段提交)
3PC,是Three-Phase Commit缩写，即三阶段提交，是2PC的改进版，将整个事务处理分为CanCommit、PreCommit、doCommit3个阶段
3PC将2PC的第一阶段一分为CanCommit、PreCommit两个阶段，来减少同不阻塞影响的范围
引入客户端超时机构，在参与者与协调者失联情况下，在等待超时之后仍会提交事务，这种容错机制，有一种赌概率的成分
这种赌概率的做法，同样会带来数据不一致的情况
TCC
TRYING 阶段主要是对业务系统做检测及资源预留
CONFIRMING 阶段主要是对业务系统做确认提交，TRYING阶段执行成功并开始执行CONFIRMING阶段时，默认CONFIRMING阶段是不会出错的。只要TRYING成功，CONFIRMING一定成功。
CANCELING 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
TCC的优点和限制
TCC事务的优点如下：
解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。
TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。
TCC事务的缺点
TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。由于网络原因，可能会重复提交和取消，需要commit和cacel接口支持幂等。
当然，对TCC事务的这个缺点是否是缺点，是一个见仁见智的事情。
到底要不要使用TCC到底要不要使用TCC事务，取决于以下几点：
是否真正有保证跨应用业务操作的原子性需求。
研发上能否投入资源开发相对应的TCC接口。
当然还有最后一点，能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。
Paxos
待补充
ZAB
待补充
