2PC（two phase commit protocol，2PC）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（Commit phase），2指两个阶段，P指准备阶段，C指提交阶段。整个事务过程由事务管理器和参与者组成，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。在计算机中部分关系数据库如 Oracle、MySQL 都支持两阶段提交协议。下面是计算机数据库进行两阶段提交的说明： 【1】准备阶段（Prepare phase）：事务管理器给每个参与者 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交。（Undo 日志是记录修改的数据，用于数据回滚，Redo 日志是记录修改后的数据，用于提交事务后写入数据文件） 【2】提交阶段（Commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息，直接给每个参与者发送回滚（Rollback）消息；否则，发送提交（Commit）消息；参与者根据事务管理器的执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放资源。 【成功情况】：

2PC 的传统方案是在数据库层面实现的，如 Oracle、MySQL都支持 2PC协议，为了统一标准减少行业内不必要的对接成本，需要制定标准化的处理模型及接口标准，国际开放标准组织Open Group 定义了分布式事务处理模型 DTP（Distributed Transaction Processing Reference Model）。 【举个例子】：新用户注册送积分

Seata 是由阿里中间件团队发起的开源项目 Fescar，后更名为 Seata，它是一个是开源的分布式事务框架。传统 2PC的问题在 Seata中得到了解决，它通过对本地关系数据库的分支事务的协调来驱动完成全局事务，无须数据库支持 XA协议，是工作在应用层的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题，它目前提供 AT模式(即2PC)及 TCC模式的分布式事务解决方案。 【Seata的设计思想如下】：Seata 的设计目标其一是对业务无侵入，因此从业务无侵入的 2PC方案着手，在传统 2PC的基础上演进，并解决 2PC方案面临的问题。Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下图是全局事务与分支事务的关系图：

Transaction Coordinator (TC)： 事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收 TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。 Transaction Manager (TM)：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向 TC发起全局提交或全局回滚的指令。 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下管辖的全部分支事务完成提交或回滚请求； 【Seata 实现 2PC与传统 2PC的差别】： 架构层次方面，传统 2PC方案的 RM实际上是在数据库层，RM本质上就是数据库自身，通过 XA协议实现，而 Seata的 RM是以 jar包的形式作为中间件层部署在应用程序这一侧的。两阶段提交方面，传统 2PC无论第二阶段的决议是 commit还是 rollback，事务性资源的锁都要保持到 Phase2完成才释放。而 Seata的做法是在 Phase1 就将本地事务提交，这样就可以省去 Phase2持锁的时间，整体提高效率。

【业务说明】：本示例通过 Seata中间件实现分布式事务，模拟三个账户的转账交易过程。两个账户在三个不同的银行(张三在bank1、李四在bank2)，bank1和bank2是两个微服务。交易过程是，张三给李四转账指定金额。

【开发环境】：【数据库】：MySQL-5.7.25 包括 bank1和 bank2两个数据库； 【JDK】：64位 jdk1.8.0_201； 【微服务框架】：spring-boot-2.1.3、spring-cloud-Greenwich.RELEASE； 【Seata客户端（RM、TM）】：spring-cloud-alibaba-seata-2.1.0.RELEASE； 【Seata服务端(TC)】：seata-server-0.7.1； 【微服务及数据库的关系】 ：【1】dtx/dtx-seata-demo/seata-demo-bank1 银行1，操作张三账户， 连接数据库bank1； 【2】dtx/dtx-seata-demo/seata-demo-bank2 银行2，操作李四账户，连接数据库bank2； 【服务注册中心】：dtx/discover-server； 【核心代码粘贴】：【1】张三的服务，开启全局事务 @GlobalTransaction和本地事务 @Transactional，并远程调用李四服务。GlobalTransactionalInterceptor 会拦截 @GlobalTransactional注解的方法，生成全局事务ID(XID)，XID会在整个分布式事务中传递。 在远程调用时，spring-cloud-alibaba-seata会拦截 Feign调用将 XID传递到下游服务。

【2】李四服务核心代码，只需要开启本地服务即可。

因 seata一阶段本地事务已提交，为防止其他事务脏读脏写需要加强隔离。 【1】脏读 select语句加 for update（会去申请全局锁），代理方法增加 @GlobalLock或 @GlobalTransaction； 【2】脏写 必须使用 @GlobalTransaction； 【3】注：如果你查询的业务的接口没有 GlobalTransactional 包裹，也就是这个方法上压根没有分布式事务的需求，这时你可以在方法上标注 @GlobalLock注解，并且在查询语句上加 for update。 如果你查询的接口在事务链路上外层有GlobalTransactional注解，那么你查询的语句只要加for update就行。设计这个注解的原因是在没有这个注解之前，需要查询分布式事务读已提交的数据，但业务本身不需要分布式事务。 若使用 GlobalTransactional注解就会增加一些没用的额外的 rpc开销比如 begin 返回xid，提交事务等。GlobalLock简化了 rpc过程，使其做到更高的性能。 

传统2PC（基于数据库 XA协议）和Seata实现 2PC的两种 2PC方案，由于Seata的0侵入性并且解决了传统 2PC长期锁资源的问题，所以推荐采用 Seata实现2PC。 Seata实现2PC要点： 【1】全局事务开始使用 @GlobalTransactional标识； 【2】每个本地事务方案仍然使用@Transactional标识； 【3】每个数据都需要创建 undo_log表，此表是 seata保证本地事务一致性的关键；

seata 是可以对多个数据源进行事务控制的，前提是一个分支事务操作一个数据源；

本文来源程序猿进阶，由javajgs_com转载发布，观点不代表Java架构师必看的立场，转载请标明来源出处