陆天炜： GoldenDB事务一致性处理机制升级历程

GoldenDB 是中兴通讯推出的一款自研的金融级交易型分布式数据。针对金融行业关注的数据库事务一致性问题，中兴通讯 GoldenDB 分布式数据库架构师陆天炜，在DTCC2019数据库大会上做了干货分享，重点介绍了 GoldenDB 的解决方案和对应的优化实践。

 

 

 

　　▲中兴通讯GoldenDB分布式数据库架构师 陆天炜

 

　　众所周知，中兴通讯的主航道产业是5G通信，但是各行各业都会使用数据库，中兴通讯提交给客户的通讯设备上面也都使用了大量的数据库，为了给客户提供更好的交付体验，大部分都是自研的产品。

 

　　从2002年开始，中兴通讯推出EBASE文件数据库，2007年推出EBASE-MEM内存数据库，做到2011年的DHSS分布式数据库，开始有了一个雏形。2014年的时候，中兴通讯开始研发了GoldenDB这个金融级的数据库，2015年的时候已经有第一个商业版本GoldenDB 1.0，并在中信银行的北京营业厅的冠字号业务上开始使用。到2016年的时候，已经在多个银行不同业务等级的生产系统上做了商用投产。2017年，中兴通讯做了另外一件事情，和中信银行一起在总行的账务系统上做了一个核心下移的测试验证，并且验证通过了，性能超过40000TPS。当时客户就决定要在2019年的时候，把核心业务的数据库，从基于小机的DB2上迁移到基于X86平台的GoldenDB上。

 

　　GoldenDB分布式数据库总体架构是什么？

 

 

 

　　GoldenDB分布式数据库总体架构分成四个重要部分：

 

　　第一部分，是计算节点集群，是多点读写模式，因为计算节点没有状态，所以可以做到横向扩容。

 

　　第二部分，是数据节点集群。在一套GoldenDB里面，可以有多个数据节点集群去承载多个不同的业务，每个数据节点集群是可以做到物理隔离的。每个集群内部根据对应的业务流量，还有存储压力，去做分片，做负载均衡。每个数据分片都是一主多备的结构，每个备机可以做容灾和读负载能力的扩展。

 

　　第三部分，全局事务管理节点，用来管理全局分布式事物的一个生命周期。它跟计算节点做交互，提供全局事务ID的分配、回收，以及全局活跃事物列表的查询功能。

 

　　第四部分，是管理节点，主要包含几个重要功能：第一，提供了一个Web控制台页面，在控制台上可以做自动的安装、更新，集群的组建，主备切换，备份恢复等各种与运维相关的操作；第二，管理节点里面还包含了元数据管理器，源数据管理器存了两部分信息，第一部分信息是GoldenDB拓扑的组网信息，包括各个集群的设备信息，主备信息、IP信息等，第二部分就是业务数据库的源数据，包括DDL、库表结构、分布状态、分布规则；第三，管理节点还提供了监控，可视化告警等与管理相关的功能。

 

　　这就是GoldenDB数据库的整体架构，对外连接业务，提供的是MySQL的标准协议。

 

　　GoldenDB现在正在做的一个事情是，在2019年底的时候要把中信银行的DB2给替换掉。下面总结了GoldenDB数据库满足金融核心功能的一些关键需求。

 

　　第一，实时一致的分布式事务控制；在做分布式事务控制的时候，能够做到实时一致，并且事务处理不影响业务原来的业务逻辑，业务原来的代码迁到GoldenDB上的时候是不需要做逻辑变更。他们原来的代码是RPG的代码，直接通过工具改成Java代码，业务开发的工作量非常少。

 

　　第二，支持同城异地容灾和一致的备份恢复，符合异地监管的一致性。GoldenDB契合金融的两个三中心架构，能够做到同城RPO为0。无论是一致的备份恢复，还是异地接管的恢复，在做备份的时候各个节点单独备份，但恢复的时候能够能恢复到全局一致的状态。所以，异地做接管的时候，虽然会有数据丢失，但是接管后的数据也是一个一致的状态，更加方便业务进行数据回补。

 

　　第三，线性横向扩展和联机数据重分布，这包含两部分内容：一个是性能的横向扩展；一个是容量的横向扩展。关于性能的横向扩展，DBProxy能做到百分之百的横向扩展，底层数据节点是瓶颈的时候，数据节点能做到95%的横向扩展。支持在线数据重分布，并且通过追增量和冻结日志的方式，能够把真正对联机交易的影响降低到秒级，一般默认的阈值配置都在5秒以下。

 

　　第四，丰富的监控体系和完善的运维能力。传统核心基于DB2或者Oracle，只有一两台设备，运维人员和DBA人员只要监控一两台设备就行，换到这个X86的分布式架构下面，可能是十几台或者几十台，这对运维体系的易用性，对监控体系的完备性要求就更高。所以，中兴通讯的GoldenDB在2018年一整年都在做这么个事情，那就是丰富监控运维体系，跟很多第三方的平台和第三方工具做对接。

 

　　如何看待GoldenDB 事务处理机制的各种问题？

 

　　1、事务理论的分布式延伸

 

　　关于GoldenDB的分布式事务处理机制，我们先看下事务处理在分布式架构有哪些延伸。我们理解的事务的一致性，其实是在事务内的原子性(原子性-A)和事物间的隔离性(隔离性-I)，以及故障时的持久性(持久性-D)，只有三者组合到一起才能保证数据的一致性(C)。

 

　　在分布式架构下，原子性的要求，是在多个数据分片上的多次操作，要么一起成功，要么一起失败；而在单机架构下，仅是一台机器上多条记录的多次操作；隔离性方面，要求多个计算节点上的不同连接，不会相互访问到在多个数据分片内未提交事务的数据；而单机数据库的隔离性，是指不同连接(处理线程或进程)不会相互访问到当前机器上未提交事务的数据；另外，从持久性角度看，分布式数据库的事务提交前必须将日志在分片主、 从节点都得到复制，主节点故障时，能在从节点上找回数据，继续完成事务；单机数据库的事务要求是，提交前必须先将日志落盘，机器宕机恢复后不丢失数据。

 

　　2、分布式事务的难点

 

　　那么，要实现分布式事务的实时一致性（保证ACID ），难点在哪？其实包括两个部分：一是部分DB提交失败，如何保证全局事务的原子性(A)；另一部分是，并发访问时，每个事务都不知道其他事务的状态，如何保证事务之间的隔离性(I)。以转账交易为例: 交易前2个账户资金余额各100，事务T1从账户1转账50到账 户2。需解决问题：在事务T1提交期间，由于DB1和DB2提交时间有空隙，若此时事务T2读取2个账户的余额，会发现余额之和是 50+100=150；存在事务T1对账户1上扣钱成功，给账户2加钱失败的情况。

 

　　3、如何保障原子性？

 

　　在业内，通常都用2PC协议保障原子性，在MySQL中就能看到很多场景，一个是MySQL里跨存储引擎的事务，二有存储引擎里bin log一致性的保障，都通过2PC实现。2PC有自己的优势，参与者在投赞成票之前可以单方面取消事务，但是也有一些局限性。第一个问题，它本身是一个阻塞式的算法，进入Prepare以后一定要成功；第二个问题是，协同者的状态其实是一个单点，协调者挂了以后，参与者没有办法继续进行下去，参与者和协调者在某些状态会等待消息，需要启动定时监控；第三问题是，正常的提交流程，日志写入数量比较大，为 2N+3 ，消息数也多，为 4N ，其中 N 为参与节点的数量。

 

　　另外，还有很多通过增加消息中间件，或者使用TCC分布式事务框架，来实现事务原子性的方案。通过业务改造保障原子性，会有额外的问题：首先，是对业务的侵入性较大，所有业务都要增加反向操作逻辑/增加额外中间件；其次，处理过程中数据存在短暂不一致或导致更新延后，原子性不能100%保障；其三，无论2PC、MQ还是TCC，都存在的一个问题，就是在2阶段提交Commit阶段，在MQ不断重试的阶段，在TCC的Confirm阶段如果出现了异常，没有办法解决，没有补救措施，必须人工干预。

 

　　至于，GoldenDB事务原子性机制如何实现？总结起来就两句话：第一句是一阶段提交。GoldenDB有一个全局事务，整体的提交是一阶段。把一个全局事务拆成由若干个子系统单独提交的一个个子事务，把这些子事务由计算节点交给对应DB去执行。执行之前，我们先在GTM那边把事务标记成活跃的状态；如果所有的DB都执行成功了，在GTM那边把事务标记为不活跃，全局事务就结束了；第二句是自动回滚补偿。遇到像转账失败的流程后，子事务在单机上会自动回滚，反馈给计算节点后，不是全部成功的，计算节点需要向数据节点下发回滚的消息。回滚补偿就是把下发回滚的操作做到数据库层面，业务层不需要做补偿交易。这种模式的优点，一是应用层无需增加额外补偿逻辑；二是，失败回滚是少数情况，整体性能高于两阶段提交，只需要一次交互就可以了，大大节省了单机资源。

 

　　4、已提交事务回滚实现和优化方式

 

　　在这一过程中，会涉及已提交事务回滚的实现和优化方式。整个过程要经历定位-遍历-生成-执行这样一个流程。通过全局事务ID所对应的Binlog提升回滚性能，数据行里会存有全局事务的ID, 当你Commit的时候，全局事务ID会随着Binlog一起进入文件里。通过Binlog里面的GTID找到这个GTID所对应的所有Binlog的语句块，然后解析Binlog，生成SQL，立刻组成新的事务，重新执行一遍。对整个操作过程，GoldenDB做了很多优化，包括表定义缓存、预分析并行查找、共享内存、key值利用、SQL格式，未来还要把正向Binlog直接生成反向 Binlog，不走SQL解析，直接走MySQL并行回放机制，直接应用到数据库。

（编辑：无锡站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!