mysql事务一致性实现原理_陆天炜： 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。无论是一致的备份恢复，还是异地接管的恢复，在做备份的时候各个节点单独备份，但恢复的时候能够能恢复到全局一致的状态。所以，异地做接管的时候，虽然会有数据丢失，但是接管后的数据也是一个一致的状态，更加方便业务进行数据回补。

第三，线性横向扩