分布式一致性
分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。
上述场景就是分布式一致性问题，追根到底，分布式一致性的根本原因在于数据的分布式操作，引起的本地事务无法保障数据的原子性引起。
分布式一致性问题的解决思路有两种，一种是分布式事务，一种是尽量通过业务流程避免分布式事务。分布式事务是直接解决问题，而业务规避其实通过解决出问题的地方(解决提问题的人)。其实在真实业务场景中，如果业务规避不是很麻烦的前提，最优雅的解决方案就是业务规避。
事务分类
分布式事务实现方案从类型上去分刚性事务、柔型事务。刚性事务：通常无业务改造，强一致性，原生支持回滚/隔离性，低并发，适合短事务。柔性事务：有业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，适合长事务。
刚性事务：XA 协议（2PC、JTA、JTS）、3PC
柔型事务：TCC/FMT、Saga（状态机模式、Aop模式）、本地事务消息、消息事务（半消息）
2PC定义
2PC全称Two-phaseCommit，中文名是二阶段提交，是XA规范的实现思路，XA规范是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。XA 接口函数由数据库厂商提供。
X/Open DTP是X/Open 组织（即现在的 Open Group ）1994定义的分布式事务处理模型。XA规模型包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。
2PC 通常使用到XA中的三个角色TM、AP
AP：事务发起方，通常为微服务自身；定义事务边界(事务开始、结束)，并访问事务边界内的资源
TM：事务协调方，事务操作总控；管理事务全局事务，分配事务唯一标识，监控事务的执行进度，负责事务的提交、回滚、失败恢复。
RM：本地事务资源，根据协调方命令进行操作；管理本地共享资源(既数据库)。
2PC流程
2PC 分成2个阶段，第一阶段：请求阶段（commit-request phase，或称表决阶段，voting phase）和第二阶段：提交阶段（commit phase）。
表决阶段：事务协调者(TM)串行给每个参与者(RM)发送Prepare消息，每个参与者要么直接返回失败，要么在本地SQL执行、记录事务日志(Undo、Redo)，但不提交，到达一种“万事俱备，只欠东风”的状态。
可以进一步将准备阶段分为以下三个步骤：
1）TM串行向每个参与者节点询问是否可以执行提交操作，并等待各参与者节点的响应。
2）参与者节点执行询问的所有SQL语句，并将Undo和Redo写入日志。
3）各参与者节点响应TM发起的询问。如果参与者节点的事务操作实际执行成功，则返回一个”success”消息；如果参与者节点的事务操作实际执行失败，则返回一个”abort”消息。
提交阶段：如果TM收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据TM的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
分支一--当TM从所有参与者节点获得的相应消息都为”success”时：
1）TM向所有参与者节点发出”正式提交(commit)”的请求。
2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
3）参与者节点向TM发送”完成”消息。
4）TM受到所有参与者节点反馈的”完成”消息后，完成事务。
分支二--如果任一参与者节点在第一阶段返回的响应消息为”abort”，或者 TM在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
1）TM向所有参与者节点发出”回滚操作(rollback)”的请求。
2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
3）参与者节点向TM发送”回滚完成”消息。
4）TM受到所有参与者节点反馈的”回滚完成”消息后，取消事务。
不管最后结果如何，第二阶段都会结束当前事务。
总结
2PC虽然将XA规范方案细化成思路，也形成了流程图，大部情况下确实能提供原子性操作，但是仍存在一定问题，所以又出现了3PC。
