分布式事务协议
解决分布式事务，也有相应的规范和协议。分布式事务相关的协议有2PC、3PC。
由于三阶段提交协议3PC非常难实现，目前市面主流的分布式事务解决方案都是2PC协议。
2PC：两阶段提交协议
两阶段提交协议：事务管理器分两个阶段来协调资源管理器。第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器的资源都预留成功，则进行第二阶段提交资源，否则资源管理器回滚资源。
2PC协议的核心是，划分出了事务参与者和协调者的角色，并将整个过程划分成prepare和commit两个阶段。
- 一阶段prepare：所有事务参与者进行预提交；直到协调者收到所有参与者的预提交后才会进入第二步；如果在协调者的超时时间内，有任意参与者的预提交preCommit没发送或未到达，都会结束事务。
- 二阶段commit：所有参与者预提交了各自的结果后，由协调者决定最终事务是成功(commit)还是失败(rollback)。
prepare：提交事务请求
commit事务提交
成功
失败
在执行prepare过程时，如果某些参与者执行事务失败、宕机或与协调者之间的网络中断，那么协调者就无法收到所有参与者的YES响应，或者某个参与者返回了No响应。此时，协调者就会进入回退流程，对事务进行回退。
2PC的缺点
二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点：
- 同步阻塞：参与者在等待协调者的指令时，其实是在等待其他参与者的响应，在此过程中，参与者是无法进行其他操作的，也就是阻塞了其运行。倘若参与者与协调者之间网络异常导致参与者一直收不到协调者信息，那么会导致参与者一直阻塞下去。
- 单点：在2PC中，一切请求都来自协调者，所以协调者的地位是至关重要的。如果协调者宕机，那么就会使参与者一直阻塞并一直占用事务资源。如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息(例如已等待Prepare响应的时长等)，所以也无法顺利处理上一个事务。
- 数据不一致：Commit事务过程中，Commit请求/Rolback请求可能因为协调者宕机，或协调者与参与者网络问题，就可能导致部分参与者没有收到Comnit/Rolack请求，而其他参与者则正常收到执行了Commit/Rollback操作，没有收到请求的参与者则继续阻塞。这时，参与者之间的数据就不再一致了。当参与者执行Camit/Rollack后会向协调者发送Ack，然而协调者不论是否收到所有的参与者的Ack，该事务也不会再有其他补救措施了，协调者能做的也就是等待超时后向事务发起者返回一个“我不确定该事务是否成功”。
- 环境可靠性依赖协调者：prepare请求发出后，等待响应，然而如果有参与者宕机或与协调者之间的网络中断，都会导致协调者无法收到所有参与者的响应。那么在2PC中，协调者会等待一定时间，然后超时后，会触发事务中断，在这个过程中，协调者和所有其他参与者都是处于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。
为此提出了三阶段提交协议（3PC）。
三阶段提交协议 3PC
与两阶段提交不同的是，三阶段提交有两个改动点。引入超时机制。同时在协调者和参与者中都引入超时机制。 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。 也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。 1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。 2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
协调者根据参与者的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下两种可能。 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。 1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。 2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。 3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。 1.发送中断请求 协调者向所有参与者发送abort请求。 2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。
该阶段进行真正的事务提交，也可以分为以下两种情况。 3.1 执行提交 1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。 2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。 3.响应反馈 事务提交完之后，向协调者发送Ack响应。 4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。 3.2 中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。 1.发送中断请求 协调者向所有参与者发送abort请求 2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。 3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息 4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。
分布式事务模式
常见分布式事务解决方案有以下4中： 1、seata 阿里分布式事务框架 2、消息队列 3、saga 4、XA
实际上，这四种常见的分布式事务解决方案，分别对应着分布式事务的四种模式：AT、TCC、Saga、XA；
四种分布式事务模式，都有各自的理论基础，分别在不同的时间被提出；每种模式都有它的适用场景，同样每个模式都有各自的代表产品；而这些代表产品，可能就是我们常见的(全局事务、基于可靠消息、最大努力通知、TCC)。
下面我们会分别来学习这4种模式（AT、TCC、Saga、XA）的分布式事务实现。
AT 模式：auto transaction
阿里seata框架，实现了该模式。
AT 模式的一阶段、二阶段提交和回滚 均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。
无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。
在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。
AT 模式如何做到对业务的无侵入 ：
一阶段：
在一阶段，Seata 会拦截“业务 SQL”。首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
二阶段提交：
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据；如果不一致就说明有脏写，出现脏写就需要转人工处理。
TCC 模式：try-Confirm-Cancel
高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。
TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。
TCC 三个方法描述：
- try：资源的检测和预留；
- confirm：执行的业务操作提交；要求 try 成功 confirm 一定要能成功；
- cancel：预留资源释放；
蚂蚁金服TCC实践,总结以下注意事项:
- 业务模型分2阶段设计
- 并发控制
- 允许空回滚
- 防悬挂控制
- 幂等控制
Saga 模式
长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统。Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。
XA模式
分布式强一致性的解决方案，但性能低而使用较少。