分布式事务及各场景解决方案

分布式事务

什么是事务?

事务可以看做一次大的活动,它由不同的小活动组成,要么全部成功,要么全部失败

本地事务

在计算机系统中,更多的是靠关系型数据库来控制事务,这是利用数据库本身的事务特性来实现的,因此叫数据库事务

四大特性

⑴ 原子性（Atomicity）

原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

⑵ 一致性（Consistency）

一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。

拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。

⑶ 隔离性（Isolation）

隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。

即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。

关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。

⑷ 持久性（Durability）

持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。

1，脏读

脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。

当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致。例如：用户A向用户B转账100元，对应SQL命令如下

    update account set money=money+100 where name=’B’;  (此时A通知B)

    update account set money=money - 100 where name=’A’;

当只执行第一条SQL时，A通知B查看账户，B发现确实钱已到账（此时即发生了脏读），而之后无论第二条SQL是否执行，只要该事务不提交，则所有操作都将回滚，那么当B以后再次查看账户时就会发现钱其实并没有转。

2，不可重复读

不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。

例如事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。

不可重复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。

在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题，例如对于同一个数据A和B依次查询就可能不同，A和B就可能打起来了……

3，虚读(幻读)

幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。

幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

现在来看看MySQL数据库为我们提供的四种隔离级别：

① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。

② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。

③ Read committed (读已提交)：可避免脏读的发生。

④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。

以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，执行效率就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。

在MySQL数据库中，支持上面四种隔离级别，默认的为Repeatable read (可重复读)；而在Oracle数据库中，只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别，其中默认的为Read committed级别。

分布式事务

分布式系统会把一个应用系统拆分成可独立部署的多个服务,因此需要服务与服务之间的远程协作才能完成事务操作,
这种分布式环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务,例如用户注册送积分事务,创建订单
减库存事务,银行转账事务等都是分布式事务

场景

1.不同服务器上的服务访问同一数据库 或 不同服务器上服务访问不同的数据库 -> 跨JVM进程产生分布式事务

2.单体体统访问多个数据库 ->跨数据库实例产生分布式事务

基础理论

分布式事务->提供服务的各个节点分布在不同的机器上,相互之间网络交互.不能因为有一点网络问题就导致整个服务不可用,因此分布式事务更需要进一步的理论支持,也就是分布式事务的CAP理论

CAP理论

CAP是Consistency, Availability, Partition tolerance三个词语的缩写,分别表示一致性,可用性,分区容错性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BY6LvbTq-1619060340634)(C:\Users\lenovo\AppData\Local\Temp\1608129652830.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Od2kQWzR-1619060340637)(C:\Users\lenovo\AppData\Local\Temp\1608129801559.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ixxj7JHh-1619060340639)(C:\Users\lenovo\AppData\Local\Temp\1608129952117.png)]

结论

在所有分布式事务场景中不会同时具备CAP三个特性,因为在具备了P的前提下C和A是不能共存的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F4ef2D5K-1619060340642)(C:\Users\lenovo\AppData\Local\Temp\1608130212554.png)]

BASE理论

CAP只能满足三项中的两项,CAP中的C指的是强一致性,但很多场景中所需要的是最终一致性,允许一段时间内的数据不一致,但最终是一致的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vIJmCipK-1619060340644)(C:\Users\lenovo\AppData\Local\Temp\1608130687768.png)]

解决方案

1.2PC

2pc指的是两阶段提交协议,将整个事务流程分为两个阶段:P -> 准备阶段, C -> 提交阶段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3BdGMiT9-1619060340650)(C:\Users\lenovo\AppData\Local\Temp\1608131244367.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gt8yvj3O-1619060340652)(C:\Users\lenovo\AppData\Local\Temp\1608131402673.png)]

失败情况:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yQnXiLPc-1619060340654)(C:\Users\lenovo\AppData\Local\Temp\1608131433369.png)]

落地方案

XA方案

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JsClxrRF-1619060340655)(C:\Users\lenovo\AppData\Local\Temp\1608131570915.png)]

执行流程:
1.应用程序(AP)持有用户库和积分库两个数据源
2.AP通过TM(事务管理器)通知用户库RM新增用户,同时通知积分库RM为该用户新增积分,RM此时并未提交事务,此时用户和积分资源锁定
3.TM收到执行回复,只要有一方失败则分别向其他RM发起回滚事务,回滚完毕,资源锁释放
4.TM收到执行回复,全部成功,此时向所有RM发起提交事务,提交完毕,资源锁释放

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ALlChLPp-1619060340657)(C:\Users\lenovo\AppData\Local\Temp\1608172064946.png)]

缺点:

1.需要数据库支持XA协议
2.资源锁需要等到两个阶段结束才释放,性能较差

Seata方案

Seata是阿里中间件团队发起的开源项目Fescar,后更名为Seata,他是一个开源的分布式事务框架,传统2PC的问题在Seata中得到了解决,他通过对本地关系数据库的分支事务的协调来驱动完成全局事务,是工作在应用层的中间件.主要优点是性能好,且不长时间占用连接资源,他以高效并且对业务0侵入的方式解决微服务下面临的分布式问题,目前提供AT模式(2PC)及	TCC模式的分布式事务解决方案

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jpYK3lqP-1619060340659)(C:\Users\lenovo\AppData\Local\Temp\1608172751223.png)]

seata中的角色

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K7x6Fo5n-1619060340660)(C:\Users\lenovo\AppData\Local\Temp\1608172891147.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ouRmcFYC-1619060340662)(C:\Users\lenovo\AppData\Local\Temp\1608172958093.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7BtauEqQ-1619060340664)(C:\Users\lenovo\AppData\Local\Temp\1608173108669.png)]

Seata实现2pc与传统2Pc的差别:

架构层次方面: 传统2PC方案的RM实际上是在数据库层,RM本质上就是数据库本身,通过XA协议来实现,二Seata的RM是以
JAR包的形式作为中间件层部署在应用程序这一测的

两阶段提交层面: 传统2PC无论第二阶段的决议是commit还是rollback,事务性资源的锁都要保持到阶段2执行完成才能释放.而Seata的做法是在一阶段就直接提交本地事务,这样可以省去到二阶段执行完这段时间,整体提高效率

正常成功提交事务流程图:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I8ea7VrO-1619060340666)(C:\Users\lenovo\AppData\Local\Temp\1608193883898.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1DWSag4V-1619060340667)(C:\Users\lenovo\AppData\Local\Temp\1608195532930.png)]

事务回滚流程图(省略RM注册过程):

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1SCBvfUK-1619060340668)(C:\Users\lenovo\AppData\Local\Temp\1608195711448.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gOpFYEKN-1619060340669)(C:\Users\lenovo\AppData\Local\Temp\1608195756831.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tGwSYEVM-1619060340671)(C:\Users\lenovo\AppData\Local\Temp\1608195883411.png)]

搭建项目:

1.先启动seata服务端(可以指定以什么方式启动 本文以file启动)角色:tc
2.微服务整合Seata的依赖 角色;rm
3.微服务中引入seata服务端的file.conf和register.conf文件,如果是file模块,那么更改file中的配置:
service{
    #vgroup->rgroup   show-ts-demo1 项目的application名 fescar-service-group 固定默认值
  vgroup_mapping.show-ts-demo1-fescar-service-group = "default"
  #only support single node
  default.grouplist = "localhost:8888" 指的是服务端地址
  #degrade current not support
  enableDegrade = false
  #disable
  disable = false
  #unit ms,s,m,h,d represents milliseconds, seconds, minutes, hours, days, default permanent
  max.commit.retry.timeout = "-1"
  max.rollback.retry.timeout = "-1"
}
4.然后在需要全局事务的方法上加@GlobalTransactional来开启全局事务

2.TCC(代码侵入真的强,不推荐)

TCC是Try,Confirm,Cancel三个词语的缩写,TCC要求每个分支事务实现三个操作:预处理Try,确认Confirm,撤销Cancel.Try操作做业务检查及资源预留,Confirm做业务确认操作,Cancel实现一个与Try相反的操作即回滚操作.
TM首先发起所有的分支事务的try操作,任何一个分支事务的try操作执行失败,TM将会发起所有分支事务的Cancel操作,
若try操作全部成功,TM将会发起所有分支事务的Confirm操作,其中Confirm/Cancel操作若执行失败,TM将会重试

分布式事务提交成功:[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ty6PM0Do-1619060340672)(C:\Users\lenovo\AppData\Local\Temp\1608262564693.png)]

分布式事务提交失败进行回滚:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R3afUN8W-1619060340673)(C:\Users\lenovo\AppData\Local\Temp\1608262602027.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BNJLxKqx-1619060340675)(C:\Users\lenovo\AppData\Local\Temp\1608272570382.png)]

TCC解决方案

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JnFypw57-1619060340676)(C:\Users\lenovo\AppData\Local\Temp\1608272749104.png)]

Hmily是一个高性能分布式事务TCC开源框架,基于java语言开发(JDK1.8),支持Dubbo,SpringCloud 等RPC框架进行分布式事务,目前支持一下特性:

1.支持嵌套事务
2.采用disruptor框架进行事务日志的异步读写,与RPC框架性能毫无差别
3.支持springboot-starter 项目启动,使用简单
4.RPC框架支持:dubbo,motan,springcloud
5.本地事务存储支持:redis,mongodb,zookeeper,file,mysql
6.事务日志序列化支持: java,hession,kryo,protostuff
7.采用Aspect AOP切面思想与Spring无缝集成,天然支持集群
8.RPC事务恢复,超时异常恢复等

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PTuFwtlf-1619060340677)(C:\Users\lenovo\AppData\Local\Temp\1608273247784.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OJjEWdB3-1619060340679)(C:\Users\lenovo\AppData\Local\Temp\1608273446893.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-A3tAbHs6-1619060340680)(C:\Users\lenovo\AppData\Local\Temp\1608273983673.png)]

3.可靠消息最终一致性(常用)

是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,
此方案强调的是只要消息发给事务参与方最终事务要达到一致

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4a8xZJml-1619060340681)(C:\Users\lenovo\AppData\Local\Temp\1608279330236.png)]

因此可靠消息最终一致性方案需要解决以下几个问题:

1.本地事务与消息发送的原子性问题

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mDjvfbz2-1619060340682)(C:\Users\lenovo\AppData\Local\Temp\1608279622081.png)]

解决方案:

在本地采用本地事务消息表的方案
例子:注册用户送积分

1.用户注册成功,数据如表
2.此时将用户注册成功的日志写入到消息表中
3.使用定时任务来扫描消息表中数据,进行定时向mq发送消息,即使发送失败,消息的状态便不会变,那么定时任务还会重新进行发送消息

以上便确保了本地事务与消息发送的原子性

2.事务参与方接收消息的可靠性

事务参与方必须能够从消息队列接收到消息,如果接收消息失败可以重复接收消息

解决方案:

参与方可用通过mq中间件的ack确认消费机制来保证消息一定被消费掉,如果监听到队列的消息,但没有ack确认的话,mq是会继续推此条消息

3.消费重复消费的问题

由于网络2的存在,若某一个消费节点超时但是消费成功,此时消费中间件就会重复投递此消息,就导致了消费的重复消费
要解决消息重复消费的问题其实就是要实现事务参与者的方法幂等性.

最终解决方案:

RocketMQ事务消息方案

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MxxgtDpG-1619060340683)(C:\Users\lenovo\AppData\Local\Temp\1608280689348.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6tAMkXAp-1619060340684)(C:\Users\lenovo\AppData\Local\Temp\1608280935584.png)]

执行流程如下：

为方便理解我们还以注册送积分的例子来描述 整个流程。

Producer 即MQ发送方，本例中是用户服务，负责新增用户。MQ订阅方即消息消费方，本例中是积分服务，负责

新增积分。

1、Producer 发送事务消息

Producer （MQ发送方）发送事务消息至MQ Server，MQ Server将消息状态标记为Prepared（预备状态），注

意此时这条消息消费者（MQ订阅方）是无法消费到的。

本例中，Producer 发送 ”增加积分消息“ 到MQ Server。

2、MQ Server回应消息发送成功

MQ Server接收到Producer 发送给的消息则回应发送成功表示MQ已接收到消息。

3、Producer 执行本地事务

Producer 端执行业务代码逻辑，通过本地数据库事务控制。

本例中，Producer 执行添加用户操作。

4、消息投递

若Producer 本地事务执行成功则自动向MQServer发送commit消息，MQ Server接收到commit消息后将”增加积

分消息“ 状态标记为可消费，此时MQ订阅方（积分服务）即正常消费消息；

 若Producer 本地事务执行失败则自动向MQServer发送rollback消息，MQ Server接收到rollback消息后 将删

除”增加积分消息“ 。

MQ订阅方（积分服务）消费消息，消费成功则向MQ回应ack，否则将重复接收消息。这里ack默认自动回应，即

程序执行正常则自动回应ack。

5、事务回查

如果执行Producer端本地事务过程中，执行端挂掉，或者超时，MQ Server将会不停的询问同组的其他 Producer

来获取事务执行状态，这个过程叫事务回查。MQ Server会根据事务回查结果来决定是否投递消息。

以上主干流程已由RocketMQ实现，对用户侧来说，用户需要分别实现本地事务执行以及本地事务回查方法，因此

只需关注本地事务的执行状态即可。

4.最大努力通知

最大努力通知也是一种解决分布式事务的方案,
和可靠消息最终一致性的区别是 本例子需要被调用方返回执行结果,而最终一致性是适用于不需要等待结果的业务
下边是一个充值的例子:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-su7NKp6i-1619060340685)(C:\Users\lenovo\AppData\Local\Temp\1608540106608.png)]

目标:发起通知方通过一定的机制最大努力将业务处理结果通知到接收方

1.有一定的消息重复通知机制

因为接收通知方可能没有接收到通知,此时要有一定的机制对消息重复通知

2.消息校对机制

如果尽最大努力也没有通知到接收方,或者接收方消费消息后要再次消费,此时可由接收方主动向通知方查询消息信息来满足需求

最大努力通知与可靠消息一致性有什么不同?

1.解决方案思想不同
可靠消息一致性,发起通知方需要保证将消息发出去,并且将消息发到接收通知方,消息的可靠性关键由发起通知方来保证

2.两者的业务场景不同
发起通知方尽最大的努力将业务处理结果通知为接收通知方,但是可能消息接收不到,此时可由接收方主动向通知方查询消息信息来满足需求

3.技术解决方向不同
可靠消息一致性要解决消息从发出到接收的一致性,即消息发出且被接受到.
最大努力通知无法保证消息从发出到接收的一致性,只提供消息接收的可靠性机制.可靠机制是最大努力的
将消息通知给接收方,当消息无法被接收方接收时,由接收方主动查询消息(业务处理结果)

解决方案

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9IFfQnBA-1619060340686)(C:\Users\lenovo\AppData\Local\Temp\1608542164278.png)]

流程:

1、用户请求充值系统进行充值。
2、充值系统完成充值将充值结果发给MQ。
3、账户系统监听MQ，接收充值结果通知，如果接收不到消息，MQ会重复发送通知。接收到充值结果通知账户系
统增加充值金额。
4、账户系统也可以主动查询充值系统的充值结果查询接口，增加金额。

第二方案:[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cxl6Jsew-1619060340687)(C:\Users\lenovo\AppData\Local\Temp\1608542517973.png)]

增加了个通知程序,也就是说如果通知系统与被通知系统不是一个内部环境(不是一个公司的),那么通知系统是一定不会把mq暴露给被通知系统的,这是会有第三个角色通知程序来进行消息的通知,一般使用http/https协议,例如(支付宝/微信)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gwinKTzt-1619060340689)(C:\Users\lenovo\AppData\Local\Temp\1608542651007.png)]

前边我们已经学习了四种分布式事务解决方案，2PC、TCC、可靠消息最终一致性、最大努力通知，每种解决方案
我们通过案例开发进行学习，本章节我们结合互联网金融项目中的业务场景，来进行分布式事务解决方案可行性分
析。

案例项目

P2P金融又叫P2P信贷。其中P2P是 peer-to-peer 或 person-to-person 的简写，意思是：个人对个人。P2P金融指
个人与个人间的小额借贷交易，一般需要借助电子商务专业网络平台帮助借贷双方确立借贷关系并完成相关交易手
续。借款者可自行发布借款信息，包括金额、利息、还款方式和时间，实现自助式借款;投资者根据借款人发布的信
息，自行决定出借金额，实现自助式借贷。
目前，国家对P2P行业的监控与规范性控制越来越严格，出台了很多政策来对其专项整治。并主张采用“银行存管模
式”来规避P2P平台挪用借投人资金的风险，通过银行开发的“银行存管系统”管理投资者的资金，每位P2P平台用户
在银行的存管系统内都会有一个独立账号，平台来管理交易，做到资金和交易分开，让P2P平台不能接触到资金，
就可以一定程度避免资金被挪用的风险。
什么是银行存管模式？
银行存管模式涉及到2套账户体系，P2P平台和银行各一套账户体系。投资人在P2P平台注册后，会同时跳转到银行
再开一个电子账户，2个账户间有一一对应的关系。当投资人投资时，资金进入的是平台在银行为投资人开设的二
级账户中，每一笔交易，是由银行在投资人与借款人间的交易划转，P2P平台仅能看到信息的流动。

注册账号案例分析

业务流程

用户向用户中心发起注册请求，用户中心保存用户业务信息，然后通知统一账号服务新建该用户所对应登录账号。

解决方案分析

针对注册业务，如果用户与账号信息不一致，则会导致严重问题，因此该业务对一致性要求较为严格，即当用户服
务和账号服务任意一方出现问题都需要回滚事务。
根据上述需求进行解决方案分析：
1、采用可靠消息一致性方案
可靠消息一致性要求只要消息发出，事务参与者接到消息就要将事务执行成功，不存在回滚的要求，所以不适用。
2、采用最大努力通知方案
最大努力通知表示发起通知方执行完本地事务后将结果通知给事务参与者，即使事务参与者执行业务处理失败发起
通知方也不会回滚事务，所以不适用。
3、采用Seata实现2PC
在用户中心发起全局事务，统一账户服务为事务参与者，用户中心和统一账户服务只要有一方出现问题则全局事务
回滚，符合要求。
实现方法如下：

1、用户中心添加用户信息，开启全局事务

2、统一账号服务添加账号信息，作为事务参与者

3、其中一方执行失败Seata对SQL进行逆操作删除用户信息和账号信息，实现回滚。

4、采用Hmily实现TCC
TCC也可以实现用户中心和统一账户服务只要有一方出现问题则全局事务回滚，符合要求。
实现方法如下：
1、用户中心
try：添加用户，状态为不可用
confirm：更新用户状态为可用
cancel：删除用户
2、统一账号服务
try：添加账号，状态为不可用
confirm：更新账号状态为可用
cancel：删除账号