分布式事务专题一直是面试的重点，这篇文章主要是讨论一下分布式事务中的2pc协议。如果你之前看过CAP和BASE理论，会对这篇文章的理解有更大的帮助。
一、什么是2pc协议
2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit
phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。
如何理解呢？比如说同学聚会，AA制。
（1）准备阶段：每个人出钱
（2）提交阶段：钱齐了付款
在这俩阶段中，任何一个环节出现了错误，整个事务都会流产。在常见的关系型数据库中就支持了2pc协议。比如有名的mysql数据库。
（1）准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事
务，并写本地的Undo/Redo日志，此时事务没有提交。
（2）提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；
下面是成功的情况：阶段1是准备阶段，阶段2是提交阶段
下面是失败的情况。
这就是失败的情况。
二、使用seata实现2pc事务
这个seata是阿里提供的分布式事务框架。Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下图是全局事务与分支事务的关系图：
Seata定义了3个组件来协议分布式事务的处理过程 。
（1）Transaction Manager (TM)：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令。
（2）Transaction Coordinator (TC)：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。
（3）Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分支（本地）事务的提交和回滚。
这些概念看起来有点懵逼，举个例子吧：拿新用户注册送积分举例Seata的分布式事务过程
具体的执行流程如下：
（1）用户服务的 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。
（2）用户服务的 RM 向 TC 注册 分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入 XID 对应全局
事务的管辖。
（3）用户服务执行分支事务，向用户表插入一条记录。
（4）逻辑执行到远程调用积分服务时(XID 在微服务调用链路的上下文中传播)。积分服务的RM 向 TC 注册分支事
务，该分支事务执行增加积分的逻辑，并将其纳入 XID 对应全局事务的管辖。
（5）积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务。
（6）用户服务分支事务执行完毕。
（7）TM 向 TC 发起针对 XID 的全局提交或回滚决议。
（8）TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。