绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
基于两阶段提交的分布式事务实现(UP-2PC)
2020-05-19 14:45:38

引言:分布式事务是分布式数据库的基础性功能,在2017年上海MySQL嘉年华(IMG)和中国数据库大会(DTCC2018)中作者都对银联UPSQL Proxy的分布式事务做了简要介绍,受限于交流形式难以做全面细致的探讨,借由本文进一步展开。

UP-2PC是面向分布式数据库的由中国银联自主研发的针对MySQL的2PC分布式事务实现,以UPSQL Proxy(分布式式数据库代理)作为事务管理器,UPSQL(MySQL银联定制版本)为资源管理器。

由于MySQL在5.7中彻底解决了xa prepare的高可用问题以及连接关闭自动回滚等问题,使得MySQL的xa真正可用。

分布式事务

如果了解分布式事务与2PC,并考虑过如下议题(不必认可),可略过本节内容:

• TCC是应用层的2PC实现

• 2PC的实现难点在于事务管理器(TM)的异常处理

• 2PC与Paxos:Paxos用于相同数据的分布式高可用存储,2PC更擅长不同数据分布式存储的事务一致性

2PC协议(Prepare,Commit, Rollback)

首先我们要提到分布式事务模型:X/Open DTP(Distributed Transaction Processing) Reference Model。

• X/Open组织定义的一套分布式事务的标准,定义了规范和API接口,由厂商进行具体的实现

• X/Open DTP定义了三个组件: AP,TM,RM

• AP(Application Program):使用分布式事务的应用

• RM(Resource Manager):资源管理器,这里可以是一个DBMS系统,或者消息服务器管理系统,资源管理器必须实现XA定义的接口

• TM(Transaction Manager):事务管理器,负责协调和管理事务

通常把TM管理的分布式事务称为全局事务,把RM管理的事务称为本地事务。

两阶段提交,是X/Open DTP的一个实现,主要在事务结束动作前加入了一个Prepare阶段:

• Prepare阶段:Prepare成功的数据,后续Commit一定会成功。

• Commit/Rollback阶段:提交或回滚数据

图例:2PC协议


DTP很早就指出资源管理器的类型不单单是数据库,还可以是消息服务。


TCC协议(Try, Confirm, Cancel)

TCC编程: 将业务逻辑拆解为Try、Confirm和Cancel三个阶段,实际上两阶段提交的变种。业务场景如:锁单、下单和取消。

TCC编程需要保证幂等性,即:可以被不断调用接口(直至符合预期),因而需要保证多次调用不会导致异常影响(如重复扣款等)。2PC的主要问题

2PC协议,主要是在如下场景的处理较为复杂:

• 同步阻塞、应答超时

• TM宕机恢复

2PC比较:数据库VS应用

比较容易取得共识的结论:不同业务系统之间使用2PC。

那剩下的问题就简单了, 相同业务系统之间是使用数据访问层2PC还是TCC?一般而言,基于研发成本考虑,会建议:新系统由数据库层来实现统一的分布式事务。

但对热点数据,例如商品(票券等)库存,建议使用TCC方案,因为TCC的主要优势正是可以避免长时间锁定数据库资源进而提高并发性。

2PC与Paxos

有一种广为流传的观点:"2PC到3PC到Paxos到Raft",即认为:

• 2PC是Paxos的残次版本

• 3PC是2PC的改进

上述2个观点都是我所不认同的,更倾向于如下认知:

• 2PC与Paxos解决的问题不同:2PC是用于解决数据分片后,不同数据之间的分布式事务问题;而Paxos是解决相同数据多副本下的数据一致性问题。例如,UP-2PC的数据存储节点可以使用MGR来管理统一数据分片的高可用

• 3PC只是2PC的一个实践方法:一方面并没有完整解决事务管理器宕机和资源管理器宕机等异常,反而因为增加了一个处理阶段让问题更加复杂

MySQL的2PC语法(XA)

MySQL提供的2PC语法(MySQL XA)如下:

XA {START|BEGIN} xid [JOIN|RESUME]
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA RECOVER [CONVERT XID]

图例:MySQL XA语法


我们针对语法组合方式略微展开。

2PC的事务提交流程

2PC提交流程为:

XA {START|BEGIN} xid [JOIN|RESUME]
/*事务操作*/
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid

2PC的事务回滚流程

2PC回滚流程为:

XA {START|BEGIN} xid [JOIN|RESUME]
/*事务操作*/
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid /*可选*/
XA ROLLBACK xid

注意回滚时Prepare阶段不是必须的,所以可以在如下场景中可以省略Prepare阶段,减少网络交互:

• 本地事务未发生写操作

• 本地事务需要回滚

当然没有Prepare阶段也就意味着,其从两阶段退化为一阶段了。

2PC退化为一阶段提交

XA语法下退化为一阶段提交的流程为:

XA {START|BEGIN} xid [JOIN|RESUME]
/*事务操作*/
XA END xid [SUSPEND [FOR MIGRATE]]
XA COMMIT xid ONE PHASE

使用XA的一阶段提交(XA COMMIT xid ONE PHASE)的一个典型场景为在全局事务中只有该本地事务有写操作,在UP-2PC因为使用"后参与者"方案,所以后参与者也会使用XA一阶段提交。

2PC恢复处理

这里指当与MySQL的交互出现异常,例如与MySQL的会话断开、MySQL宕机等,如何获取并恢复处于Prepare状态下的2PC事务,并进行提交或回滚处理。

mysql> XA RECOVER;

UP-2PC技术实现

UP-2PC要解决的核心问题正是如何处理:事务管理器、资源管理器异常,以及可能的网络。

• 事务管理器(TM)突然宕机以及网络异常,导致协调信息丢失。典型的:异常发生后,处于Prepare状态的RM,正确进行后续处理(rollback和commit)

• 部分资源管理器(RM)突然宕机以及网络异常,导致的信息协调。典型的:全局事务内多个Prepare状态,此时若部分RM发生本异常,则TM如何处理,可选方案:

1.全局事务向请求者应答成功,由事务事务管理器后续提交异常RM

2.回滚所有RM,并向前端应答事务提交失败

通过上述探讨,可以发现2PC的主要难点在于:

• 事务状态信息维护:全局事务状态(TM)、本地事务状态(RM)

• 根据事务状态信息的异常处理策略

毫无疑问事务状态信息不丢失,是实现安全2PC的基础,由于本地事务状态信息可以通过MySQL高可用集群解决,所以我们仅需要:保证全局事务状态(TM)不丢失。

分布式事务的工程实践

在给出UP-2PC的方案之前,我们可以先了解下已有的分布式事务工程实践经验,“Distributed transactions in Spring, with and without XA”(Spring的分布式事务,使用或不用XA;Spring分布式事务的7种实现)是一篇不错的文章,很好总结了既有实践经验,这里仅对其中涉及XA的两种优化方案进行说明:

• 一阶段提交优化:如果全局事务只涉及一个RM,则不使用两阶段

• 后参与者优化(Last Participant Support):选择一个RM(后参与者)不使用两阶段提交,全局事务提交时,先对”后参与者”进行(一阶段)提交.该策略又被称为:后资源提交优化(Last Resource Commit Optimization)。

图例:后参与者优化

乍看起来“后参与者优化”方案效果有限,但事实上该方案直接指明了UP-2PC的实现路径,因为:

1.“一阶段提交优化”可以视为“后参与者优化”的特例,即只全局事务只包含一个RM时两者等效

2.“后参与者优化”指出了后参与者在所有RM中为重要,其事务提交结果决定着全局事务的结果,而前面也提到了全局事务状态是重要的,所以我们自然推导出应该由后参与者记录全局事务状态(我们称为xa-log)

UP-2PC核心方案

UP-2PC核心方案,包含3点:

1.利用RM节点分布式存全局事务状态信息(xa-log)

2.使用后参与者协议

3.由后参与者记录全局事务状态信息(xa-log)

xa-log中记录了全局事务id所涉及的所有资源管理器节点列表,和对应的本地xid,以及全局事务状态(commit|rollback)。

这里仅对全局事务需要进行commit做下说明,如果后参与者commit成功,则认为全局事务commit成功,若后参与者commit成功而其他资源管理器异常,则交由异常处理程序轮询xa-log表完成其他资源管理器的xa commit操作。

后参与者的选择策略:如果个本地事务参与者如果发生了写操作,则选择其为后参与者;否则在其他发生了写操作的参与中随机选择。该选择策略实现了后参与者的分布式随机选择,进而保证xa-log的分布式随机分布。

图例:UP-2PC实现


如图所示,UP-2PC的实现要点在于:

1.全局事务提交,则由后参与者记录xa-log

2.后参与者提交前,需要保证其他参与则处于prepare状态

3.在所有参与者事务提交结束后,删除xa-log

UP-2PC异常处理

在确保全局事务状态(xa-log)安全保存后,就可以针对2PC的各种异常进行处理。

不考虑TM异常,将异常按时间线进行区分:

1.全局事务commit之前:因为没有执行本地xa和xa-log的相关操作,则按事务提交失败处理

2.全局事务执行commit阶段:

– xa-log记录与prepare阶段异常:则回滚所有本地事务

– 后参与者commit异常:则查询xa-log,如xa-log有全局事务的com mit记录,则视为事务提交成功;没有则视为提交失败;查询结果不确定 (如后参与者宕机等),则事务状态不确定,可以考虑断开与AP连接(即不应答AP事务状态), 或保持连接直至得到查询结果未知。

– 其他参与者commit异常:依然应答全局事务成功,交由后续异步commit。

其他异常及异常处理: 以xa-log记录为准,对比xa-log与RM的xa-id信息进行对比分析进行提交或回滚操作。

需要指出的是由于TM是集群多机部署,所以xaid在编码时需要能区分不同TM节点信息。

与TDSQL分布式事务实现的区别

在已公开的同类产品中TDSQL与UP-2PC的解决思路为接近,这里做下简单对比。

图例:TDSQL与UP-2PC对比;注:示例来自TDSQL的公开介绍材料,为简化描述略作修改

UP-2PC相对TDSQL的分布式事务解决方案主要区别在于UP-2PC采用了后参与者策略,由后参与者进行xa-log记录。

优点:减少启用一个数据库会话、一次网络交互、减少一个事务、退化一个2PC事务为一阶段

缺点:业务数据库用户需要具有xa-log的读写权限,因而具有运维风险,特别是在复用数据库实例的情况下

一次进一步展开思考,TDSQL不使用后参与者策略的理由可能如下:

• 作为云上产品,应尽可能避免运维风险

• XA业务场景占比较少,性能影响有限

• 方便将来xa-log由其他方式存储

UP-2PC性能优化

在实现UP-2PC方案后,XA分布式事务的性能影响大约为30%(依赖场景),虽然符合预期,但也说明需要进一步优化。

这里给出UP-2PC两个性能优化方案:

• 本地事务启动优化

• MySQL XA协议优化

本地事务启动优化

对于属于不可重复读的全局事务,我们可以延迟开启本地事务以减少资源锁定时间。

本地事务启动优化的核心策略:

1.全局事务为不可重复读

2.本地事务只有发生了写才需要开启本地XA事务

针对如下业务场景:

/*事务隔离级别为read-commited或read-uncommited*/
Begin;
select db1 and db2; //1st
update db1;
update db2;
select db1 and db2; //2nd
Commit;

我们推演下全局事务管理器对上述语句的处理逻辑:

1.当次执行查询操作时,由于db1和db2都未发生写操作,则不必开启本地事务,在查询结束后可以将本地事务会话归还连接池。

2.在遇到次写入操作时,分别开启对应的本地事务管理器。

3.在后续查询时,由于已持有本地事务连接,则使用该连接进行查询操作。

而实际的场景中,可能操作如下:

Begin;
select db1 and db2;
update db1;
select db1 and db2;
Commit;

即全局事务内,查询的节点数量多于更新的节点数量,通过本方案只会对写入数据库节点开启本地XA事务,从而避免了不必要的事务开启操作。

MySQL XA协议优化

在实现UP-2PC的过程中我们一直有这样一个设计期望:在全局事务只涉及一个本地事务,我们能否对该事务不启用xa协议?

在我们实现“本地事务启动优化”后,这个问题视乎解决了,因为让后参与者不使用XA协议就可以轻松实现了上述目标,但后参与者不使用XA协议可能会导致我们无法解决后面提及的分布式死锁问题。

于是我们转换思路,对我们的设计目标的本质进行剖析,即XA一阶段提交与传统事务提交有什么区别?

答案:多了一个xa end。

于是XA协议优化方案也就呼之欲出,即省略掉不必须要的XA END。

图例:UP-2PC优化方案

如图所示,通过减少了xa end阶段,减少了交互次数自然提高了系统健壮性,也提高了性能。

分布式事务带来的新问题

在实现了基于2PC的分布式事务,对外提供统一事务管理特征,也会引入一些新问题,例如:

• 分布式事务死锁

• 对外XA协议支持(外部2PC)

• Savepoint支持

这里仅对部分解决方案进行说明。

分布式事务死锁

由于分布式事务管理多个RM,所以必然会带来分布式资源竞争和分布式死锁。例如:

• 会话a 和 b 开启分布式事务

• time 1: a write db1.resource1

• time 2: b write db2.resource2

• time 3: a write db2.resource2 -> 锁:a 等待b的 db2.resource2

• time 4: b write db1.resource1 -> 锁:b 等待a的 db1.resource1

在时间点4, a和b发生了资源循环等待,从而出现了分布式死锁。

如何解决分布式死锁呢,这里提供一种死锁检测方法:

• 扩展innodb_trx表,增加事务xid的记录

• TM层确保同一全局事务所对应的本地事务xid相同

这样就可以对所有全局事务的锁信息进行分析,并发现分布式死锁。

下表为扩展innodb_trx的效果,由于代码修改较为简单这里就不累述。

另一种方法是在本地事务中加入事务时间信息,在RM层根据时间先后顺序,保证只会存在单一时序的资源等待,从而避免死锁发生。

对外XA协议支持(外部2PC)

如果我们将应用UP-2PC的数据库集群视为一个整体,则实现分布式事务的过程为内部2PC,对外部应用提供2PC协议支持(即支持XA协议),则称为外部2PC。数据集群的内部外部2PC,可以与MySQL的内部外部2PC对应理解。

该逻辑较为简单,即在外部执行XA PREPARE时,我们在xa-log中记录全局事务状态为Prepare即可,需要指出的是:外部2PC下,内部的分布式事务无法使用前述的后参与者优化方案。

图例:外部两XA协议实现


总结

本文介绍了UP-2PC的具体实现,涵盖了核心解决方案与异常处理策略、性能优化、带来的新问题与解决方案。

分享好友

分享这个小栈给你的朋友们,一起进步吧。

TDSQL专区
创建时间:2020-05-19 14:26:20
一键解锁TDSQL全部资料。
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

技术专家

查看更多
  • 小雨滴
    专家
戳我,来吐槽~