分布式事务解决方案,SQLServer2000分布式事务错误解决方法

分布式事务解决方案,SQLServer2000分布式事务错误解决方法详细介绍

本文目录一览： Dubbo的分布式事务怎么解决

　　目前比较多的解决方案有几个：
　　一、结合MQ消息中间件实现的可靠消息最终一致性
　　二、TCC补偿性事务解决方案
　　三、最大努力通知型方案
　　第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态
　　第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。
　　TRYING阶段主要是对业务系统进行检测及资源预留
　　CONFIRMING阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。默认如果TRYING阶段执行成功，CONFIRMING就一定能成功。
　　CANCELING阶段是回对业务做回滚，在TRYING阶段中，如果存在分支事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。
　　第三种方案：最大努力通知xing型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不再通知。

MSSQL server分布式事务解决方案

适用环境操作系统：windows 2003数据库：sql server 2000/sql server 2003使用链接服务器进行远程数据库访问的情况一、问题现象在执行分布式事务时，在sql server 2005下收到如下错误：消息 7391，级别 16，状态 2，过程 xxxxx，第 16 行无法执行该操作，因为链接服务器 "xxxxx" 的 OLE DB 访问接口 "SQLNCLI" 无法启动分布式事务。在sql server 2000下收到如下错误：该操作未能执行，因为 OLE DB 提供程序 'SQLOLEDB' 无法启动分布式事务。[OLE/DB provider returned message: 新事务不能登记到指定的事务处理器中。 ]OLE DB 错误跟踪［OLE/DB Provider 'SQLOLEDB' ITransactionJoin::JoinTransaction returned 0x8004d00a］。二、解决方案1.双方启动MSDTC服务MSDTC服务提供分布式事务服务，如果要在数据库中使用分布式事务，必须在参与的双方服务器启动MSDTC（Distributed Transaction Coordinator）服务。2.打开双方135端口MSDTC服务依赖于RPC（Remote Procedure Call (RPC)）服务,RPC使用135端口，保证RPC服务启动，如果服务器有防火墙，保证135端口不被防火墙挡住。使用“telnet IP 135 ”命令测试对方端口是否对外开放。也可用端口扫描软件（比如Advanced Port Scanner）扫描端口以判断端口是否开放。3.保证链接服务器中语句没有访问发起事务服务器的操作在发起事务的服务器执行链接服务器上的查询、视图或存储过程中含有访问发起事务服务器的操作，这样的操作叫做环回（loopback），是不被支持的，所以要保证在链接服务器中不存在此类操作。4.在事务开始前加入set xact_abort ON语句对于大多数 OLE DB 提供程序（包括 SQL Server），必须将隐式或显示事务中的数据修改语句中的 XACT_ABORT 设置为 ON。唯一不需要该选项的情况是在提供程序支持嵌套事务时。5.MSDTC设置打开“管理工具——组件服务”，以此打开“组件服务——计算机”，在“我的电脑”上点击右键。在MSDTC选项卡中，点击“安全配置”按钮。在安全配置窗口中做如下设置：l选中“网络DTC访问”l在客户端管理中选中“允许远程客户端”“允许远程管理”l在事务管理通讯中选“允许入站”“允许出站”“不要求进行验证”l保证DTC登陆账户为：NTAuthority\NetworkService6.链接服务器和名称解析问题建立链接sql server服务器，通常有两种情况:l第一种情况，产品选”sql server”EXEC sp_addlinkedserver@server='linkServerName',@srvproduct = N'SQL Server'这种情况，@server （linkServerName）就是要链接的sqlserver服务器名或者ip地址。l第二种情况，访问接口选“Microsoft OLE DB Provider Sql Server”或“Sql Native Client”EXEC sp_addlinkedserver@server=' linkServerName ',@srvproduct='',@provider='SQLNCLI',@datasrc='sqlServerName'这种情况，@datasrc（sqlServerName）就是要链接的实际sqlserver服务器名或者ip地址。Sql server数据库引擎是通过上面设置的服务器名或者ip地址访问链接服务器，DTC服务也是通过服务器名或者ip地址访问链接服务器，所以要保证数据库引擎和DTC都能通过服务器名或者ip地址访问到链接服务器。数据库引擎和DTC解析服务器的方式不太一样，下面分别叙述6.1数据库引擎第一种情况的@server或者第二种情况的@datasrc设置为ip地址时，数据库引擎会根据ip地址访问链接服务器，这时不需要做名称解析。第一种情况的@server或者第二种情况的@datasrc设置为sql server服务器名时，需要做名称解析，就是把服务器名解析为ip地址。有两个办法解析服务器名：一是在sql server客户端配置中设置一个别名，将上面的服务器名对应到链接服务器的ip地址。二是在“C:\WINDOWS\system32\drivers\etc\hosts”文件中增加一条记录：xxx.xxx.xxx.xxx服务器名作用同样是把服务器名对应到链接服务器的ip地址。6.2DTC不管哪一种情况，只要@server设置的是服务器名而不是ip地址，就需要进行名称解析，办法同上面第二种办法，在hosts文件中增加解析记录，上面的第一种办法对DTC不起作用。如果@server设置的是ip地址，同样不需要做域名解析工作。

SQLServer2000分布式事务错误解决方法

分类: 电脑/网络 >> 互联网
解析:

SQLServer2000分布式事务错误解决方法 如果在Windows.NETServer上安装的SQLServer2000中运行链接服务器查询，可能会返回下列错误（即使MSDTC正在该服务器上运行）：
症状如果在Windows.NETServer上安装的SQLServer2000中运行链接服务器查询，可能会返回下列错误（即使MSDTC正在该服务器上运行）：Server：Msg8501，Level16，State3，Line3 MSDTConserver'servername'isunavailable.在SQLServer错误日志中，您会发现由运行该查询的spid引发的下列错误：ResourceManagerCreationFailed：ResultCode=0x8004d01c原因这是设计使然。如果在"本地系统"帐户下运行"分布式事务处理协调器服务"就会发生此错误。解决方案最近为了提高RPC安全性对DTC所做的更改要求MSDTC作为"NTAuthority\NeorkService"运行。这是。NETServer的默认选项。在WindowsNT和Windows2000中，默认情况下MSDTC服务是在"本地系统"帐户下运行的。
警告："注册表编辑器"使用不当可造成严重问题，这些问题可能需要重新安装操作系统。Microsoft不保证能够解决因为"注册表编辑器"使用不当而产生的问题。使用"注册表编辑器"需要您自担风险。
若要将MSDTC服务帐户从"本地系统"更改为"NTAuthority\NeorkService"，请执行下列步骤：1.运行regedt32，浏览至HKEY_LOCAL_MACHINE\Sofare\Microsoft\MSDTC.添加一个DWORD值TurnOffRpcSecurity，值数据为1.2.打开命令提示，运行"stopmsdtc"，然后运行"startmsdtc".3.转至"组件服务管理工具".

a.浏览至"启动管理工具".
b.选择"组件服务".
c.展开"组件服务"树，然后展开"我的电脑".
d.右键单击"我的电脑"，然后选择"属性".
e.在MSDTC选项卡中，确保选中了下列选项：网络DTC访问网络管理网络事务XA事务另外，"DTC登录帐户"一定要设置为"NTAuthority\NeorkService".
f.单击"确定".这样将会提示您"MSDTC将会停止并重新启动。所有的依赖服务将被停止。请按'是'继续".单击"是"继续。
g.单击"确定"关闭"我的电脑"属性窗口。
4.再次运行regedt32，浏览至HKEY_LOCAL_MACHINE\Sofare\Microsoft\MSDTC，然后删除TurnOffRpcSecurity项。现在您的MSDTC服务应该在"NTAuthority\NeorkService"帐户下运行了，并且不会再出现该错误。
更多信息当"MSDTC安全性"配置下的"网络DTC访问"禁用时，如果运行链接服务器查询则会返回下列错误：Server：Msg7391，Level16，State1，Line2TheoperationcouldnotbeperformedbecausetheOLEDBprovider'SQLOLEDB'
wasunabletobeginadistributedtransaction.[OLE/DBproviderreturnedmessage：Newtransactioncannotenlistinthespecifiedtransactioncoordinator.]
跟踪标记7300打开时：Server：Msg7391，Level16，State1，Line2TheoperationcouldnotbeperformedbecausetheOLEDBprovider'SQLOLEDB'
wasunabletobeginadistributedtransaction.[OLE/DBproviderreturnedmessage：Newtransactioncannotenlistinthespecifiedtransactioncoordinator.]OLEDBerrortrace[OLE/DBProvider'SQLOLEDB'ITransactionJoin：：JoinTransactionreturned0x8004d00a].
MSDTC服务一定要按照上面"解决方案"一节中的说明进行设置，才能防止此错误。
再现现象的步骤
1.转至"启动管理工具服务".
2.右键单击"分布式事务处理协调器"服务，转至"登录"选项卡，选择"登录身份"下的"本地系统"帐户。
3.停止然后重新启动该服务。
4.从查询分析器，运行下列脚本：execsp_addlinkedserverremote1execsp_setnameremote1，

goexecremote1.pubs.dbo.sp_executesqlN'createtablet（c1int）'gosetxact_abortongobegintraninsertintoremote1.pubs.dbo.tvalues（1）mittrango

深入理解分布式事务，高并发下分布式事务的解决方案

1、什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2、分布式事务的产生的原因

2.1、数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

2.2、应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！

3、事务的ACID特性

3.1、原子性（A）

所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。

3.2、一致性（C）

事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。

3.3、隔离性（I）

所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

3.4、持久性（D）

所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

4、分布式事务的应用场景

4.1、支付

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的操作必然需要引入分布式事务。

4.2、在线下单

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

5、常见的分布式事务解决方案

5.1、基于XA协议的两阶段提交

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

5.2、消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：

1、A系统向消息中间件发送一条预备消息

2、消息中间件保存预备消息并返回成功

3、A执行本地事务

4、A发送提交消息给消息中间件

通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：

步骤一出错，则整个事务失败，不会执行A的本地操作步骤二出错，则整个事务失败，不会执行A的本地操作步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作，其中B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作，如果本地操作失败，消息会重投，直到B操作成功，这样就变相地实现了A与B的分布式事务。原理如下：

虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

5.3、TCC编程模式

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

6、总结

分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力

分布式事务（3）--seate

Seate控制分布式事务：
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
官网： http://seata.io/zh-cn/
可以查看帮助文档 http://seata.io/zh-cn/docs/overview/what-is-seata.html

1、每一个微服务先必须创建一个表 undo_log
2、安装事务协调器：seate-server
3、整合
1）导入依赖 spring-cloud-starter-alibaba-seate 引用的是seate-all-0.7.1版本
2）解压并启动seate-server
registry.conf 注册中心配置：修改registry type=nacos
file.conf
3) 所有想要用到分布式事务的微服务使用seate DataSourceProxy代理自己的数据源
4）每个微服务都必须导入
registry.conf
file.conf 修改 vgroup_mapping.{application.name}-fescar-service-group="default"
5) 启动测试分布式事务
6）给分布式大失误的入口标注@GlobalTransactional
7) 给每一个远程的小事务 用@Transactional 标注

以上我们使用的是Seate的AT模式，也就是2PC模式的一个演变。我们看Seate的一个实现方式，发现中间加了很多的锁机制，这就限制了它不太适合高并发的应用场景。比较适合并发量很低的使用场景，比如：后台管理中商品的添加，商品添加过程中处理积分，代金券等其他关联的远程服务的一个场景。

分布式事务解决方案ServiceComb - Omega源码阅读与分享

ServiceComb已经是Apache的顶级项目，包含两个组件，即 alpha 和 omega。

源码地址：https://github.com/apache/servicecomb-pack

alpha 是事务协调中心，保存事务日志，通过日志协调各个分支
demo 里面项目的各框架的例子：spring和dubbo saga tcc
docs 设计文档，最先应该熟悉的。
omega 负责与alpha通讯，子事务逻辑
pack-contracts gRPC通讯接口定义文件,通过中间文件生成客户端与服务端面代码，让开发者不必关心通讯过程
web 用angular写的web界面，可以查看事务的状态。
我们主要关注的alpha和omega的代码，gRPC知识是通讯基础非常重要，最好先了解gRPC和probuf、Kyro序列化对阅读源码
还是很有帮助的。但通讯部分只是简单带过。
GlobalTxId全局事务ID标记子事务是否同属性一个事务中
ParentTxId 父类的事务ID
localTxId子事务Id
Omega会面向切面编程的方式，向程序中注入相应的逻辑，初始化事务上下文OmegaContext,在事务处理的过程中向alpha报告事务状态，

实现saga协调协议和TCC协调协议,下面就是omega客户端要配置了三个信息
omega.enable=true或@EnableOmega的作用只标记开启Omega，Omega在SpringBoot上初始化过程：
OmegaSpringAutoConfiguration 通过@Configuration，在Spring框架启动时加载并配置
OmegaSpringConfig
作用：初始化各Bean,IdGenerator用来生成子事务Id Saga的事件Sender Tcc事件Sender回调CallbackContext
TransactionAspectConfig
对@SagaStart @Compensable注解AOP的切面编程对象初始
Omega内部机制：SagaStartAspect @SagaStart的AOP切面编程

TransactionAspect对@Compensable注解AOP切面编程

成功场景下，每个事务都会有开始和对应的结束事件。
TransactionAspect=>DefaultRecovery=>CompensableInterceptor

封装了通讯组件：dubbo fegin resttemplate servicecomb实现的通讯
这些组件各自通讯的基础上，在服务之间相互调用时，把globalTxId和localTxId传递过去，并注入Context中
如：omega-transport->omega-transport-resttemplate
RestTemplateConfig 配置拦截器TransactionClientHttpRequestInterceptor
TransactionClientHttpRequestInterceptor：把当前的上下文的globalTxId和localTxId放到请求里
TransactionHandlerInterceptor 服务提供者，把resttemplate传递过来的globalTxId和localTxId放到当前上下文里，
pack-contracts->pack-contract-grpc
gRPC的接口服务定义文件：GrpcCommon.proto GrpcTccEvent.protogrpcTxEvent.proto：这些文件在protobuf命令直接编译成java代码。
如何使用请看：proto文件gRpc基础
谢谢能看到最后的人：我分享我是怎么阅读源码的。源码阅读不能一上来就找到main入口一行一行的看。最先应该了解基本的组成架构、和用到了哪些技术栈，如果还用了你从来没见的技术，建议先去学习这门新的技术，再回头来看代码，熟悉了各模块相对应的功能后。我会找到一个切入口，猜一下它的实现方式，再根据猜测，带着疑问，去找答案。如果对整个项目的模块不是很清楚，最好先把源码里的Demo正常的运行。通过这样的简单学习，一步步的深入。有的代码的抽象是比较复杂的。可先跳过，当你对整个结构都非常了解了，这时再回头去读剩下的难点。最后有个总结有个对比就是最好结果。

Java分布式系统处理分布式事务有哪些经典解决方

当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题：
1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。
2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。
于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。 通常，我们会通过两种手段来扩展我们的数据服务：
1）数据分区：就是把数据分块放在不同的服务器上（如：uid % 16，一致性哈希等）。
2）数据镜像：让所有的服务器都有相同的数据，提供相当的服务。
对于第一种情况，我们无法解决数据丢失的问题，单台服务器出问题时，会有部分数据丢失。所以，数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储（一般工业界认为比较安全的备份数应该是3份，如：Hadoop和Dynamo）。 但是，加入更多的机器，会让我们的数据服务变得很复杂，尤其是跨服务器的事务处理，也就是跨服务器的数据一致性。这个是一个很难的问题。 让我们用最经典的Use Case：“A帐号向B帐号汇钱”来说明一下，熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作：
从A帐号中把余额读出来。
对A帐号做减法操作。
把结果写回A帐号中。
从B帐号中把余额读出来。
对B帐号做加法操作。
把结果写回B帐号中。
为了数据的一致性，这6件事，要么都成功做完，要么都不成功，而且这个操作的过程中，对A、B帐号的其它访问必需锁死，所谓锁死就是要排除其它的读写操作，不然会有脏数据的问题，这就是事务。那么，我们在加入了更多的机器后，这个事情会变得复杂起来：
1）在数据分区的方案中：如果A帐号和B帐号的数据不在同一台服务器上怎么办？我们需要一个跨机器的事务处理。也就是说，如果A的扣钱成功了，但B的加钱不成功，我们还要把A的操作给回滚回去。这在跨机器的情况下，就变得比较复杂了。
2）在数据镜像的方案中：A帐号和B帐号间的汇款是可以在一台机器上完成的，但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作（要汇给B和C），这两个操作发生在不同的两台服务器上怎么办？也就是说，在数据镜像中，在不同的服务器上对同一个数据的写操作怎么保证其一致性，保证数据不冲突？
同时，我们还要考虑性能的因素，如果不考虑性能的话，事务得到保证并不困难，系统慢一点就行了。除了考虑性能外，我们还要考虑可用性，也就是说，一台机器没了，数据不丢失，服务可由别的机器继续提供。 于是，我们需要重点考虑下面的这么几个情况：
1）容灾：数据不丢、节点的Failover
2）数据的一致性：事务处理
3）性能：吞吐量 、 响应时间
前面说过，要解决数据不丢，只能通过数据冗余的方法，就算是数据分区，每个区也需要进行数据冗余处理。这就是数据副本：当出现某个节点的数据丢失时可以从副本读到，数据副本是分布式系统解决数据丢失异常的唯一手段。所以，在这篇文章中，简单起见，我们只讨论在数据冗余情况下考虑数据的一致性和性能的问题。简单说来：
1）要想让数据有高可用性，就得写多份数据。
2）写多份的问题会导致数据一致性的问题。
3）数据一致性的问题又会引发性能问题
这就是软件开发，按下了葫芦起了瓢。
一致性模型
说起数据一致性来说，简单说有三种类型（当然，如果细分的话，还有很多一致性模型，如：顺序一致性，FIFO一致性，会话一致性，单读一致性，单写一致性，但为了本文的简单易读，我只说下面三种）：
1）Weak 弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些cache系统，网络游戏其它玩家的数据和你没什么关系，VOIP这样的系统，或是百度搜索引擎（呵呵）。
2）Eventually 最终一致性：当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件、Amazon S3，Google搜索引擎这样的系统。
3）Strong 强一致性：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。
从这三种一致型的模型上来说，我们可以看到，Weak和Eventually一般来说是异步冗余的，而Strong一般来说是同步冗余的，异步的通常意味着更好的性能，但也意味着更复杂的状态控制。同步意味着简单，但也意味着性能下降。 好，让我们由浅入深，一步一步地来看有哪些技术：
Master-Slave
首先是Master-Slave结构，对于这种加构，Slave一般是Master的备份。在这样的系统中，一般是如下设计的：
1）读写请求都由Master负责。
2）写请求写到Master上后，由Master同步到Slave上。
从Master同步到Slave上，你可以使用异步，也可以使用同步，可以使用Master来push，也可以使用Slave来pull。 通常来说是Slave来周期性的pull，所以，是最终一致性。这个设计的问题是，如果Master在pull周期内垮掉了，那么会导致这个时间片内的数据丢失。如果你不想让数据丢掉，Slave只能成为Read-Only的方式等Master恢复。
当然，如果你可以容忍数据丢掉的话，你可以马上让Slave代替Master工作（对于只负责计算的节点来说，没有数据一致性和数据丢失的问题，Master-Slave的方式就可以解决单点问题了） 当然，Master Slave也可以是强一致性的， 比如：当我们写Master的时候，Master负责先写自己，等成功后，再写Slave，两者都成功后返回成功，整个过程是同步的，如果写Slave失败了，那么两种方法，一种是标记Slave不可用报错并继续服务（等Slave恢复后同步Master的数据，可以有多个Slave，这样少一个，还有备份，就像前面说的写三份那样），另一种是回滚自己并返回写失败。（注：一般不先写Slave，因为如果写Master自己失败后，还要回滚Slave，此时如果回滚Slave失败，就得手工订正数据了）你可以看到，如果Master-Slave需要做成强一致性有多复杂。
Master-Master
Master-Master，又叫Multi-master，是指一个系统存在两个或多个Master，每个Master都提供read-write服务。这个模型是Master-Slave的加强版，数据间同步一般是通过Master间的异步完成，所以是最终一致性。 Master-Master的好处是，一台Master挂了，别的Master可以正常做读写服务，他和Master-Slave一样，当数据没有被复制到别的Master上时，数据会丢失。很多数据库都支持Master-Master的Replication的机制。
另外，如果多个Master对同一个数据进行修改的时候，这个模型的恶梦就出现了——对数据间的冲突合并，这并不是一件容易的事情。看看Dynamo的Vector Clock的设计（记录数据的版本号和修改者）就知道这个事并不那么简单，而且Dynamo对数据冲突这个事是交给用户自己搞的。就像我们的SVN源码冲突一样，对于同一行代码的冲突，只能交给开发者自己来处理。（在本文后后面会讨论一下Dynamo的Vector Clock）
Two/Three Phase Commit
这个协议的缩写又叫2PC，中文叫两阶段提交。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。

微服务架构的分布式事务问题如何处理？

可以参考开源分布式事务管理器ByteTCC。ByteTCC特性：
1、支持Spring容器的声明式事务管理；
2、支持普通事务、TCC事务、业务补偿型事务等事务机制；
3、支持多数据源、跨应用、跨服务器等分布式事务场景；
4、支持长事务；
5、支持dubbo服务框架；
6、支持spring cloud；
7、提供框架层面的幂等性解决方案；
1. 性能和时延问题
在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗：
1） 客户端需要对消息进行序列化，主要占用CPU计算资源。
2） 序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。
3） 客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。
4） 服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。
5） 服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。
6） 服务端将响应结果序列化，占用CPU计算资源。
7） 服务端将应答码流发送给客户端，占用网络带宽资源。
8） 客户端读取应答码流，反序列化成响应消息，占用CPU资源。
通过分析我们发现，一个简单的本地方法调用，切换成远程服务调用之后，额外增加了很多处理流程，不仅占用大量的系统资源，同时增加了时延。一些复杂
的应用会拆分成多个服务，形成服务调用链，如果服务化框架的性能比较差、服务调用时延也比较大，业务服务化之后的性能和时延将无法满足业务的性能需求。
1.1　RPC框架高性能设计
影响RPC框架性能的主要因素有三个。
1） I/O调度模型：同步阻塞I/O（BIO）还是非阻塞I/O（NIO）。
2） 序列化框架的选择：文本协议、二进制协议或压缩二进制协议。
3） 线程调度模型：串行调度还是并行调度，锁竞争还是无锁化算法。
1. I/O调度模型
在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。I/O多路复用技术通过把多个I/O的
阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O多路复用的最大
优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。
JDK1.5_update10版本使用epoll替代了传统的select/poll，极大地提升了NIO通信的性能，它的工作原理如图1-1所示。
图1-1　非阻塞I/O工作原理
Netty是一个开源的高性能NIO通信框架：它的I/O线程NioEventLoop由于聚合了多路复用器Selector，可以同时并发处理成
百上千个客户端Channel。由于读写操作都是非阻塞的，这就可以充分提升I/O线程的运行效率，避免由于频繁I/O阻塞导致的线程挂起。另外，由于
Netty采用了异步通信模式，一个I/O线程可以并发处理N个客户端连接和读写操作，这从根本上解决了传统同步阻塞I/O一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。
Netty被精心设计，提供了很多独特的性能提升特性，使它做到了在各种NIO框架中性能排名第一，它的性能优化措施总结如下。
1） 零拷贝：（1）Netty的接收和发送ByteBuffer采用DIRECT
BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP
BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送
过程中多了一次缓冲区的内存拷贝。（2）Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer
那样方便地对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。（3）Netty的文件传输采用
了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。
2）
内存池：随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于
堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty提供了基于内存池的缓冲区重用机制。性能测试表明，采用内存池的
ByteBuf相比于朝生夕灭的ByteBuf，性能高23倍左右（性能数据与使用场景强相关）。
3）
无锁化的串行设计：在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导
致性能的下降。为了尽可能地避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多
线程竞争和同步锁。为了尽可能提升性能，Netty采用了串行无锁化设计，在I/O线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行
化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设
计相比一个队列-多个工作线程模型性能更优。
4） 高效的并发编程：volatile的大量、正确使用；CAS和原子类的广泛使用；线程安全容器的使用；通过读写锁提升并发性能。
2. 高性能序列化框架
影响序列化性能的关键因素总结如下。
1） 序列化后的码流大小（网络带宽的占用）。
2） 序列化&反序列化的性能（CPU资源占用）。
3） 是否支持跨语言（异构系统的对接和开发语言切换）。
4） 并发调用的性能表现：稳定性、线性增长、偶现的时延毛刺等。
相比于JSON等文本协议，二进制序列化框架性能更优异，以Java原生序列化和Protobuf二进制序列化为例进行性能测试对比，结果如图1-2所示。
图1-2　序列化性能测试对比数据
在序列化框架的技术选型中，如无特殊要求，尽量选择性能更优的二进制序列化框架，码流是否压缩，则需要根据通信内容做灵活选择，对于图片、音频、有大量重复内容的文本文件（例如小说）可以采用码流压缩，常用的压缩算法包括GZip、Zig-Zag等。
3. 高性能的Reactor线程模型
该模型的特点总结如下。
1） 有专门一个NIO线程：Acceptor线程用于监听服务端，接收客户端的TCP连接请求。
2） 网络I/O操作：读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送。
3） 1个NIO线程可以同时处理N条链路，但是1个链路只对应1个NIO线程，防止产生并发操作。
由于Reactor模式使用的是异步非阻塞I/O，所有的I/O操作都不会导致阻塞，理论上一个线程可以独立处理所有I/O相关的操作，因此在绝大多数场景下，Reactor多线程模型都可以完全满足业务性能需求。
Reactor线程调度模型的工作原理示意如图1-3所示。
图1-3　高性能的Reactor线程调度模型
1.2　业务最佳实践
要保证高性能，单依靠分布式服务框架是不够的，还需要应用的配合，应用服务化高性能实践总结如下：
1） 能异步的尽可能使用异步或者并行服务调用，提升服务的吞吐量，有效降低服务调用时延。
2） 无论是NIO通信框架的线程池还是后端业务线程池，线程参数的配置必须合理。如果采用JDK默认的线程池，最大线程数建议不超过20个。因为JDK的线程池默认采用N个线程争用1个同步阻塞队列方式，当线程数过大时，会导致激烈的锁竞争，此时性能不仅不会提升，反而会下降。
3）
尽量减小要传输的码流大小，提升性能。本地调用时，由于在同一块堆内存中访问，参数大小对性能没有任何影响。跨进程通信时，往往传递的是个复杂对象，如果
明确对方只使用其中的某几个字段或者某个对象引用，则不要把整个复杂对象都传递过去。举例，对象A持有8个基本类型的字段，2个复杂对象B和C。如果明确
服务提供者只需要用到A聚合的C对象，则请求参数应该是C，而不是整个对象A。
4） 设置合适的客户端超时时间，防止业务高峰期因为服务端响应慢导致业务线程等应答时被阻塞，进而引起后续其他服务的消息在队列中排队，造成故障扩散。
5） 对于重要的服务，可以单独部署到独立的服务线程池中，与其他非核心服务做隔离，保障核心服务的高效运行。
6） 利用Docker等轻量级OS容器部署服务，对服务做物理资源层隔离，避免虚拟化之后导致的超过20%的性能损耗。
7） 设置合理的服务调度优先级，并根据线上性能监控数据做实时调整。
2. 事务一致性问题
服务化之前，业务采用本地事务，多个本地SQL调用可以用一个大的事务块封装起来，如果某一个数据库操作发生异常，就可以将之前的SQL操作进行回滚，只有所有SQL操作全部成功，才最终提交，这就保证了事务强一致性，如图2-1所示。
服务化之后，三个数据库操作可能被拆分到独立的三个数据库访问服务中，此时原来的本地SQL调用演变成了远程服务调用，事务一致性无法得到保证，如图2-2所示。
图2-2　服务化之后引入分布式事务问题
假如服务A和服务B调用成功，则A和B的SQL将会被提交，最后执行服务C，它的SQL操作失败，对于应用1消费者而言，服务A和服务B的相关
SQL操作已经提交，服务C发生了回滚，这就导致事务不一致。从图2-2可以得知，服务化之后事务不一致主要是由服务分布式部署导致的，因此也被称为分布
式事务问题。
2.1　分布式事务设计方案
通常，分布式事务基于两阶段提交实现，它的工作原理示意图如图2-3所示。
图2-3　两阶段提交原理图
阶段1：全局事务管理器向所有事务参与者发送准备请求；事务参与者向全局事务管理器回复自己是否准备就绪。
阶段2：全局事务管理器接收到所有事务参与者的回复之后做判断，如果所有事务参与者都可以提交，则向所有事务提交者发送提交申请，否则进行回滚。事务参与者根据全局事务管理器的指令进行提交或者回滚操作。
分布式事务回滚原理图如图2-4所示。
图2-4　分布式事务回滚原理图
两阶段提交采用的是悲观锁策略，由于各个事务参与者需要等待响应最慢的参与者，因此性能比较差。第一个问题是协议本身的成本：整个协议过程是需要加
锁的，比如锁住数据库的某条记录，且需要持久化大量事务状态相关的操作日志。更为麻烦的是，两阶段锁在出现故障时表现出来的脆弱性，比如两阶段锁的致命缺
陷：当协调者出现故障，整个事务需要等到协调者恢复后才能继续执行，如果协调者出现类似磁盘故障等错误，该事务将被永久遗弃。
对于分布式服务框架而言，从功能特性上需要支持分布式事务。在实际业务使用过程中，如果能够通过最终一致性解决问题，则不需要做强一致性；如果能够避免分布式事务，则尽量在业务层避免使用分布式事务。
2.2　分布式事务优化
既然分布式事务有诸多缺点，那么为什么我们还在使用呢？有没有更好的解决方案来改进或者替换呢？如果我们只是针对分布式事务去优化的话，发现其实能改进的空间很小，毕竟瓶颈在分布式事务模型本身。
那我们回到问题的根源：为什么我们需要分布式事务？因为我们需要各个资源数据保持一致性，但是对于分布式事务提供的强一致性，所有业务场景真的都需
要吗？大多数业务场景都能容忍短暂的不一致，不同的业务对不一致的容忍时间不同。像银行转账业务，中间有几分钟的不一致时间，用户通常都是可以理解和容忍
的。
在大多数的业务场景中，我们可以使用最终一致性替代传统的强一致性，尽量避免使用分布式事务。
在实践中常用的最终一致性方案就是使用带有事务功能的MQ做中间人角色，它的工作原理如下：在做本地事务之前，先向MQ发送一个prepare消
息，然后执行本地事务，本地事务提交成功的话，向MQ发送一个commit消息，否则发送一个rollback消息，取消之前的消息。MQ只会在收到
commit确认才会将消息投递出去，所以这样的形式可以保证在一切正常的情况下，本地事务和MQ可以达到一致性。但是分布式调用存在很多异常场景，诸如
网络超时、VM宕机等。假如系统执行了local_tx()成功之后，还没来得及将commit消息发送给MQ，或者说发送出去由于网络超时等原因，MQ
没有收到commit，发生了commit消息丢失，那么MQ就不会把prepare消息投递出去。MQ会根据策略去尝试询问（回调）发消息的系统
（checkCommit）进行检查该消息是否应该投递出去或者丢弃，得到系统的确认之后，MQ会做投递还是丢弃，这样就完全保证了MQ和发消息的系统的
一致性，从而保证了接收消息系统的一致性。
3. 研发团队协作问题
服务化之后，特别是采用微服务架构以后。研发团队会被拆分成多个服务化小组，例如AWS的Two Pizza Team，每个团队由2~3名研发负责服务的开发、测试、部署上线、运维和运营等。
随着服务数的膨胀，研发团队的增多，跨团队的协同配合将会成为一个制约研发效率提升的因素。
3.1　共用服务注册中心
为了方便开发测试，经常会在线下共用一个所有服务共享的服务注册中心，这时，一个正在开发中的服务发布到服务注册中心，可能会导致一些消费者不可用。
解决方案：可以让服务提供者开发方，只订阅服务（开发的服务可能依赖其他服务），而不注册正在开发的服务，通过直连测试正在开发的服务。
它的工作原理如图3-1所示。
图3-1　只订阅，不发布
3.2　直连提供者
在开发和测试环境下，如果公共的服务注册中心没有搭建，消费者将无法获取服务提供者的地址列表，只能做本地单元测试或使用模拟桩测试。
还有一种场景就是在实际测试中，服务提供者往往多实例部署，如果服务提供者存在Bug，就需要做远程断点调试，这会带来两个问题：
1） 服务提供者多实例部署，远程调试地址无法确定，调试效率低下。
2） 多个消费者可能共用一套测试联调环境，断点调试过程中可能被其他消费者意外打断。
解决策略：绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式将以服务接口为单位，忽略注册中心的提供者列表。
3.3　多团队进度协同
假如前端Web门户依赖后台A、B、C和D
4个服务，分别由4个不同的研发团队负责，门户要求新特性2周内上线。A和B内部需求优先级排序将门户的优先级排的比较高，可以满足交付时间点。但是C和
D服务所在团队由于同时需要开发其他优先级更高的服务，因此把优先级排的相对较低，无法满足2周交付。
在C和D提供版本之前，门户只能先通过打测试桩的方式完成Mock测试，但是由于并没有真实的测试过C和D服务，因此需求无法按期交付。
应用依赖的服务越多，特性交付效率就越低下，交付的速度取决于依赖的最迟交付的那个服务。假如Web门户依赖后台的100个服务，只要1个核心服务没有按期交付，则整个进度就会延迟。
解决方案：调用链可以将应用、服务和中间件之间的依赖关系串接并展示出来，基于调用链首入口的交付日期作为输入，利用依赖管理工具，可以自动计算出调用链上各个服务的最迟交付时间点。通过调用链分析和标准化的依赖计算工具，可以避免人为需求排序失误导致的需求延期。
3.4　服务降级和Mock测试
在实际项目开发中，由于小组之间、个人开发者之间开发节奏不一致，经常会出现消费者等待依赖的服务提供者提供联调版本的情况，相互等待会降低项目的研发进度。
解决方案：服务提供者首先将接口定下来并提供给消费者，消费者可以将服务降级同Mock测试结合起来，在Mock测试代码中实现容错降级的业务逻辑（业务放通），这样既完成了Mock测试，又实现了服务降级的业务逻辑开发，一举两得。
3.5　协同调试问题
在实际项目开发过程中，各研发团队进度不一致很正常。如果消费者坐等服务提供者按时提供版本，往往会造成人力资源浪费，影响项目进度。
解决方案：分布式服务框架提供Mock桩管理框架，当周边服务提供者尚未完成开发时，将路由切换到模拟测试模式，自动调用Mock桩；业务集成测试和上线时，则要能够自动切换到真实的服务提供者上，可以结合服务降级功能实现。
3.6　接口前向兼容性
由于线上的Bug修复、内部重构和需求变更，服务提供者会经常修改内部实现，包括但不限于：接口参数变化、参数字段变化、业务逻辑变化和数据表结构变化。
在实际项目中经常会发生服务提供者修改了接口或者数据结构，但是并没有及时知会到所有消费者，导致服务调用失败。
解决方案：
1） 制定并严格执行《服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。
2） 接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段，字段定义位置无关性，码流支持乱序等。
分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！
下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！
如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：
1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；
2、支付平台中创建支付订单（选银行卡支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；
3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；
4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；
5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；
如上图，支付平台收到银行扣款结果后的内部处理流程：
1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；
2、支付订单服务根据银行扣款结果更改支付订单状态；
3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；
4、调用积分服务给用户积分账户增加积分；
5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；
6、调用通知服务将支付处理结果通知电商平台；
如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：
/** 支付订单处理 **/
@Transactional(rollbackFor = Exception.class)
public void completeOrder() {
orderDao.update(); // 订单服务本地更新订单状态
accountService.update(); // 调用资金账户服务给资金帐户加款
pointService.update(); // 调用积分服务给积分帐户增加积分
accountingService.insert(); // 调用会计服务向会计系统写入会计原始凭证
merchantNotifyService.notify(); // 调用商户通知服务向商户发送支付结果通知
}
本地事务控制还可行吗？
以上分布式事务问题，需要多种分布式事务解决方案来进行处理。
订单处理：本地事务
资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。
会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）
商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）

seata分布式事务原理是什么？

Seata框架是一个业务层的XA（两阶段提交）解决方案。在理解Seata分布式事务机制前，我们先回顾一下数据库层面的XA方案。
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager (TM)： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。