2.3 GoldenDB数据库的前世今生
数据库是最难迁移的软件技术之一，银行业被称为数据库领域皇冠上的珍珠。2020年，中信银行和中兴通讯联合打造的GoldenDB分布式数据库在中信银行总行核心系统的使用，证明了国产自研分布式数据库摘取皇冠珍珠的能力，也为我国金融行业落实安全可控的国家战略提供了参考和借鉴。但GoldenDB数据库的前世今生，要从2014年开始谈起。
2014年，是一个值得记忆的年份。
2014年，开源、开放的软件技术和硬件产品在互联网企业快速发展的过程中得到了充分的验证，使用开源、开放的软硬件产品来支撑银行核心业务系统的条件已经具备可行性。
2014年，中信银行正式启动GoldenDB分布式数据库的研发，当时可谓大势所趋，生逢其时。首先，安全可控的国家战略要求银行IT从传统封闭式架构向开源、开放、自主可控的架构转型；其次，高并发交易的出现要求银行IT架构支持纵向扩展；最后，银行经营环境的变化要求银行IT基础设施从昂贵的IOE设施向x86服务器、本地磁盘等低成本设施转型。
2.3.1 GoldenDB数据库的研发和运用历程
GoldenDB作为一款金融级分布式数据库，要求支撑总行核心系统和信用卡核心系统等大型交易系统，实现中信银行IT架构从传统架构向分布式架构的转型。那么，金融级分布式数据库应满足哪些数据库技术要求？
第一，数据实时一致，具有完整的事务管理功能，交易一旦完成，交易内所有操作的结果都要求反映在数据库中。
第二，线性扩展，性能不够加机器、容量不够加机器，加机器不能停业务。
第三，高可用，软件宕机不丢数，硬件故障可恢复，包括单点故障容错、机房故障容错甚至是城市灾难恢复。
第四，数据安全可靠，安全、完备的用户鉴权、权限控制、防SQL注入能力。
第五，开发和运维简单，像使用单机数据库一样，应用程序无须额外考虑分布式事务补偿、数据分库分表处理，要求具备完善的开发工具和监控体系支撑。
除了从技术层面满足以上要求外，更重要的是以中信银行实际业务（特别是核心系统）的使用场景为依据，自2014年以来，中信银行和中兴通讯开始联合研发GoldenDB分布式数据库。
在研发的过程中，技术团队砥砺前行，产品的功能逐渐增强，性能逐渐稳定，并陆续在中信银行冠字号系统、门户网站系统、金融同业合作平台等系统得到成功运用。特别是信用卡核心下移并于2019年10月26日上线投产，总行核心业务系统于2020年5月3日上线投产。核心系统上线后经历了网联的双11测试，数据库系统表现平稳，性能比原有架构有显著提升。具体的研发和使用历程如下。
2013年，中信银行在布局的数据银行战略规划中，首次提出了由传统架构向云计算分布式架构转型的目标。
2014年5月，正式启动了GoldenDB金融级分布式数据库的研发项目，以开发一个具有强一致性、线性扩展和高可用性，可以更好地满足业务发展需要的金融级分布式数据库。
2015年7月，GoldenDB分布式数据库1.0版本正式发布。
2015年9月，中信银行冠字号系统上线。
2016年5月，中信银行门户网站系统上线。
2016年11月，中信银行金融同业合作平台上线。
2017年6月，中信银行零售客户统一积分系统上线。
2019年9月，中信银行电子渠道（对私）业务处理平台上线。
2019年10月，中信银行信用卡核心系统上线。
2020年5月，中信银行核心银行系统上线。
2.3.2 GoldenDB数据库逻辑架构
GoldenDB分布式数据库采用了层次化和组件化设计，实现了计算节点与数据存储分离，交易数据流与批量数据流分离，如图2-16所示。
图2-16 GoldenDB分布式数据库架构
如图2-16所示，整个GoldenDB分布式数据库共分为五个部分：数据库客户端、前置中间件、数据节点集群、后置中间件和管理控制台。
1．数据库客户端
数据库客户端提供了标准JDBC驱动实现，通过驱动访问DBProxy，发起SQL请求。
2．前置中间件
包括DBProxy、全局事务管理器GTM和Manager管理组件。DBProxy是数据库的访问入口，负责SQL解析、执行计划优化、SQL执行和SQL路由分发；GTM负责分布式事务管理；Manager管理组件负责集群管理、DBProxy管理和元数据管理。
3．数据节点集群
集群由数据节点和负责数据节点管理的DBAgent构成，每个数据节点采用基于MySQL进行开发的存储引擎，每个DBAgent负责数据节点的管理，例如，数据节点故障切换等。
4．后置中间件
负责批量数据的导入导出、数据重分布，实现交易数据流与批量数据流分离。
5．管理控制台
提供分布式数据库安装部署、配置管理、任务管理、告警管理和性能监控等功能。
2.3.3 GoldenDB数据库部署架构
商业银行重要系统通常采用两地三中心部署，包括生产中心、同城灾备中心和异地灾备中心。其中，生产中心和同城灾备中心位于一个城市，异地灾备中心位于另外一个城市。GoldenDB数据库支持跨中心部署，所有硬件和软件都采用冗余部署，可以避免单点故障。
如图2-17所示，来自外围系统的服务请求按照负载均衡策略被分发给生产中心和同城灾备中心部署的应用；应用包括联机交易应用和批处理应用集群，采用同城双活部署，满足异地灾备5级标准。
图2-17 GoldenDB分布式数据库架构
联机交易应用和批处理应用集群访问DBProxy集群，DBProxy无状态，容易水平扩展；DBProxy集群访问数据库集群，数据库集群包括多个分片，每个分片包括一个主库和若干个跨中心从库，主库和同城从库之间采用快同步（见2.3.4节对快同步的解释）复制，主库和异地从库之间采用异步复制。
在分布式环境下，数据库集群中的数据通过分片规则，被打散并存放在多个数据节点上，不但要保证单一数据节点数据一致性，而且要保证所有数据节点数据的一致性。GoldenDB为此设计出集群（Cluster）、安全组（Group）、工作组（Team）、响应数（Response Number）和高低水位（HLWM）的概念。
在分布式数据库系统中，最大的逻辑单位被称为集群，一个分布式数据库系统可以同时存在多个集群。每个集群由多个安全组构成，每个安全组又被称为分片。每个安全组由最多三个工作组构成，每个工作组由实际的数据节点组成。为保证每个安全组数据一致性，安全组内使用快同步或者异步复制组建主备复制关系，一个安全组内只允许存在一个主节点，其余数据节点均为从节点。通常，主节点所在工作组被称为本地工作组，负责对外提供服务。其余从节点所在的工作组被称为同城工作组或异地工作组，负责同步主节点数据、主备切换。
如图2-17所示，一个大的数据库集群跨越生产中心、同城灾备中心和异地灾备中心，共有40个安全组（即40个分片），在每个安全组内共计有3个工作组，即每个中心各有一个。每个分片内部只有一个主节点，生产中心有一个从节点，同城灾备中心有其余两个从节点，异地灾备中心有其余两个从节点，即“一主五从”结构。
主从节点数据同步时，从节点未完成数据同步之前，主节点事务无法完成提交操作，这就可以强迫从节点与主节点数据保持一致。但从节点数量越多主机事务提交就越慢，因此，可以通过高低水位与响应数的设置来进行控制，既能保证从节点数据一致性，又能避免提交过慢的问题。
响应数功能作用于工作组内，即使工作组中存在多个数据节点，通过设置响应数，可以控制工作组内满足数据一致性要求的数据节点数量，从而避免由于从节点过多，导致主节点事务提交变慢的问题。例如，工作组内有两个从节点，如果响应数设置为2，表示两个从库都要和主库保持一致性；如果响应数设置为1，表示只要其中一个从库和主库保持一致性即可。
高低水位分为高水位与低水位两个指标，其功能作用于工作组上。按照本地、同城两个工作组说明，高水位要求两个工作组同时满足数据一致性要求，否则会触发告警。低水位要求两个工作组起码一个满足数据一致性要求，否则整个安全组数据只读。
在上述部署架构的保证下，GoldenDB能够在高吞吐效率的情况下，达到同城灾备RPO=0、RTO<5 min；异地灾备RPO<2 min，RTO<10 min，并且支持异地孤岛演练。
2.3.4 GoldenDB数据库关键创新技术
在GoldenDB数据库研发中，每一项技术的开发都慎之又慎。开发团队从国内外分布式数据库技术调研开始，优先开发既能代表发展潮流又能解决实际问题的技术，接下来进行原型开发，并对原型进行大量的功能和性能的测试验证，完成所有验证后才会在GoldenDB数据库中进行产品化实现。
在GoldenDB数据库中，做了很多有利于应用的微创新，例如，在MySQL原生隔离级的基础上，又进行了扩展，增加了非一致性读（UR）、一致性读（CR）与非一致性写（SW）、一致性写（CW）四种分布式隔离级，具体详见2.3.5节中对分布式隔离级的讲解；增加了来自DBProxy的SQL查询语句的执行计划查看功能，即扩展了Explain命令；支持多级分片，对一个表按照不同规则分片，降低应用迁移难度；为应用提供全局唯一的序列值，用于全局唯一的流水号、日志号等。
除了上述微创新外，还有三大最关键的创新技术。这些技术包括实时一致的分布式事务控制、主从快同步复制支持、在线数据重分布等，下面具体论述。
1．实时一致的分布式事务控制
事务一致性指的是事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。
为保证分布式事务一致性，业界主要有两种方案：两阶段提交（2PC）方案与最终一致性（Eventual Consistency）方案。由于两阶段提交存在同步阻塞、一致性读隔离级别下脏读问题，无法满足隔离性，已证明在某些场景下无法使用；最终一致性方案又分为提供补偿事务方案和基于消息队列异步处理方案两种，但都只能保证最终一致性，不能保证实时一致性。下面具体讲述两种方案。
提供补偿事务方案要求业务为每一笔失败事务添加补偿操作，使得业务代码量增大，加之补偿事务本身也需要额外异常处理，导致处理逻辑变得复杂。并且，事务处理步骤变多，失败后全部回滚的成本也会增高。
基于消息队列异步处理方案要求将事务拆成多个本地子事务，子事务之间通过消息队列衔接，保证子事务串行执行。单个子事务占用资源时间短，可提供高并发读。但为保证事务最终一致性，应用需做大量异常处理工作以确保事务原子性。
按照银行业务对实时一致性的要求，充分分析各种事务一致性方案的优缺点后，GoldenDB数据库采用了基于全局事务ID（Global Transaction ID，GTID）的分布式事务一致性方案，在保证系统性能的同时实现数据读写操作的实时一致性，详见2.3.5节具体介绍。这也是GoldenDB数据库最为关键的技术创新。
2．GoldenDB快同步复制
MySQL原生的异步复制存在缺陷：无法保证主备数据的一致性，主机不需要等备机的响应，所以在主备切换的时候无法保证备机的数据和主机完全一致。
MySQL在异步复制的基础上提供了一个半同步插件，要求必须收到一个备机的应答响应才让事务在主机上提交，当备机应答超时的情况下，半同步会自动退化成异步模式。该方案在主机本身无故障的情况下，能保证不丢失事务，一旦退化成异步复制就回到上面的问题上去了。同时，半同步复制采用的是阻塞方式调用，存在以下两个方面的不足。
（1）在跨网络的环境下，由于网络延迟较大，导致性能非常低。
（2）线程内部调用都是同步调用，在等待备机响应期间线程只能等待，性能较低。
在保障主备数据一致性的基础上为了提升跨网络的性能，提出了快同步方案：主要针对半同步进行优化处理，增加了线程池处理逻辑，重点优化了半同步等待备机响应处理流程和事务提交机制，新增了组管理机制和高低水位阈值机制。
快同步方案的主要优化点如下。
（1）半同步复制使用的是一个连接一个线程模型，快同步使用的是连接池模型。
（2）半同步复制在等待备机响应时使用线程同步等待，快同步优化成线程不等待，收到响应后由线程池中的commit线程提交。
（3）半同步复制仅可以配置等待多个备机，无法按需分组，快同步可将备机按需分组进行管理。
半同步复制超时后退化为异步处理，快同步超时不会退化为异步，而是通过高低水位设置产生错误码告警。
3．在线数据重分布
如图2-18所示，当执行在线重分布操作时，对当前节点存量数据迁移和增量数据追平都无须停服务，仅在最后锁表切换时短暂暂停服务，可控制在1 min以内。具体步骤如下。
（1）按扩容后的分发策略创建新表。
（2）导出存量数据并导入到新表。
（3）将数据迁移期间产生的增量数据更新到新表。
（4）锁当前表并追平增量数据。
（5）切换表名，启用新分发策略。
（6）删除旧表。
图2-18 GoldenDB在线数据重分布
2.3.5 GoldenDB数据库事务的ACID特性
在数据库系统中，一个数据库事务是指由一系列数据库操作组成的一个完整的逻辑过程。例如，银行转账，从原账户扣除金额，以及向目标账户添加金额，这构成一个完整的逻辑过程，不可拆分。这个过程被称为一个事务，具有ACID特性，事务的ACID特性在ISO/IEC标准中有详细说明。
事务的ACID特性，是指数据库管理系统在写入或更新数据的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性（Atomicity，又称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）和持久性（Durability）。
GoldenDB数据库从事务研发设计上，根据规范要求全部实现了ACID属性，下面展开讲述。
1．事务原子性
事务原子性指的是一个事务要么全部提交成功，要么全部失败回滚，不能只执行其中的一部分操作。单机环境通过回滚满足全部失败的要求，但在分布式环境下，事务牵扯多个数据节点，全部失败的要求被扩大化。对于部分提交成功、部分失败的情况，GoldenDB设计实现了已提交事务回滚功能，来满足此要求。
设计原理是在数据节点上部署一个用于回滚的模块。当出现部分提交成功、部分失败的情况时，回滚命令会发送到提交成功的节点，回滚模块根据命令来完成回滚操作，如图2-19所示。
图2-19 已提交事务回滚示意图
2．事务一致性
按照银行业务对实时一致性的要求，充分分析各种事务一致性方案的优缺点后，GoldenDB采用了基于全局事务ID（Global Transaction ID，GTID）的分布式事务一致性方案。该方案把协调者（Coordinator）和全局事务管理（Global Transaction Manager，GTM）两个功能分开。GTM仅管理全局事务状态，由计算节点（DBProxy）充当协调者。并且，GTM支持本地持久化与备机同步，确保全局事务状态信息不丢失，如图2-20所示。
图2-20 基于GTID的事务管理方案
GTID方案的核心思想，是在全局事务提交过程中，发生部分节点提交失败时，回滚已提交节点数据，而不进行提交失败重试，保证数据最终一致性，同时解决同步阻塞问题。
GTID是由GTM创建的一个具有全局唯一属性的值。为保存该值，创建数据表时GoldenDB会自动添加一列。因此，GTID属于关键字，不允许显式创建名为GTID的字段。
GTM通过状态机维护每个GTID的变化。GTM为每个新事务创建一个GTID，此时状态为CREATED。在事务执行过程中，GTID伴随数据一起写入数据节点，此时状态为ACTIVE。事务发起提交，若提交成功，状态变为RELEASING；若提交失败，状态保持ACTIVE不变。提交成功后，事务正常结束，状态变为RELEASED。提交失败后，触发已提交事务回滚机制。若回滚成功，状态变为RELEASING，若回滚失败，状态保持ACTIVE不变。回滚完成后，状态变为RELEASED。对于回滚失败且状态为ACTIVE的GTID，则需要手动处理。状态切换如图2-21所示。
图2-21 GTID生命周期状态机
3．事务的隔离性
事务的隔离性指的是数据库必须保证一个事务在执行中不受其他并发事务影响。即一个事务对其他事务是隔离的，并发执行时各事务间不能互相干扰。单机环境通过设置隔离级别，控制事务之间的影响程度。同样地，针对分布式事务，GoldenDB提供了四种读写隔离级别，分别为：非一致性读（UR）、一致性读（CR）与非一致性写（SW）、一致性写（CW）。下面主要介绍分布式环境下，读写操作之间的影响与写写操作之间的影响。
分布式下的读写操作，在UR隔离级别下，读事务不会判断写事务产生的中间结果，直接返回满足条件的记录，存在脏读问题。CR隔离级别下，读事务会判断数据的状态。即写事务在提交过程中，数据处于ACTIVE状态，读事务不直接返回记录，而是按照配置进行重试操作，直到写事务提交成功或失败。因此，不会出现脏读问题。
分布式下的写写操作，在SW隔离级别下，写事务不再受到全局事务控制，写事务之间影响与单机环境类似。区别在于，已提交事务回滚无法保证数据一致性。即待回滚数据会被其他写事务修改，回滚后会丢失数据，存在非一致性写问题。CW隔离级别下，写事务受到全局事务控制，其他写事务会判断数据活跃状态。若数据活跃，则该事务无法进行写操作。因此，可以保证数据一致性。
4．事务持久性
事务持久性指的是事务提交后，对数据的修改就是永久的，即便系统故障也不会丢失。与单机事务一样，分布式事务也需要保证事务持久性。不同的是，分布式事务不但需要持久化业务数据，而且还需要持久化全局事务状态。数据持久化由数据节点保证，全局事务状态持久化由GTM保证。
GTM采用实时增量与定时全量方式对全局事务状态进行持久化。对于短事务，由于GTID被不断地创建与释放，GTM会实时地使用增量方式进行持久化；对于长事务，GTM需要长时间保存GTID，因此，每隔一定时间使用全量方式进行持久化。