实战 | 追求卓越，砥砺前行 ——中信银行 GoldenDB 分布式数据库转型实践

本文选自《金融电子化》2020年2月刊

文 中信银行数据中心 王飞鹏

随着金融科技快速发展，中信银行与时俱进，引入了分布式数据库，旨在打造金融行业最顶级的分布式数据库产品。中信银行总行核心系统将在2020年下移到自主研发的GoldenDB分布式数据库之上。中信银行引入的任何创新技术都紧紧围绕着银行客户需求，为银行客户创造更大的价值，以及更便捷、更快速和更贴心的服务。首先从分布式系统的CAP理论开始谈起。

1.CAP理论

2000年，加州大学伯克利分校的EricBrewer教授首次提出了CAP设想。2002年，麻省理工学院的SethGilbert和NancyLynch证明了CAP设想的可行性。所谓CAP，指的是一致性（Consistency）、可用性（Availability）和分区容错性（Partitiontolerance）的缩写。CAP定理指出一个分布式系统在一次操作中不可能同时满足一致性、可用性和分区容错性，最多只能同时满足其中的两项。

与集中式系统相比，分布式系统无法避免网络故障。当分布式系统出现网络故障时，基于CAP理论，为确保分区容错性，只能从一致性和可用性中二者择其一。当选择一致性时，系统要么直接返回错误，要么不返回任何结果，等待触发超时。当选择可用性时，系统会及时给接收到的请求返回结果，但不保证结果数据是最新的。

DB2、Oracle等属于CA类系统；Cassandra属于AP类系统；GoldenDB属于CP类系统。

2.GoldenDB分布式数据库

GoldenDB是一款金融级交易型分布式数据库，是国内首个在大型股份制银行核心业务系统使用的国产数据库。

见图所示，为GoldenDB典型架构，所有节点部署在生产A机房和同城B机房。整个集群包括前置计算节点DBProxy、集群管理节点Manager、数据库节点DB和全局事务管理器GTM。计算节点无状态，可以任意增加；集群管理节点生产机房为HA部署，同城之间采用快同步复制；数据库节点之间采用快同步复制；全局事务管理器节点之间采用实时增量与定时全量方式同步。

 图  GoldenDB分布式数据库架构

3.分布式事务的ACID

在分布式系统中，一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。就是要保证分布式事务的ACID，即原子性、一致性、隔离性和持久性。

事务原子性（A）：事务原子性指的是事务中的所有操作，要么全部完成，要么全部失败。在分布式环境下，事务牵扯多个数据节点，对于部分提交成功，部分失败的情况，GoldenDB设计实现了已提交事务回滚功能，来满足此要求。

当出现部分提交成功，部分失败情况时，回滚命令会发送到提交成功的节点，回滚模块根据命令来完成回滚操作。

事务一致性（C）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。写入的数据必须完全符合所有的预设约束、触发器等规则。

事务的隔离性（I）：数据库必须保证一个事务在执行中不受其他并发事务影响的能力。即一个事务对其他事务是隔离的，并发执行时各事务间不能互相干扰。单机环境通过设置隔离级别，控制事务之间影响程度。GoldenDB也提供四种读写隔离级别，分别为：非一致性读（UR）、一致性读（CR）、非一致性写（SW）、一致性写（CW）。

事务持久性（D）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。分布式事务不但需要持久化业务数据，而且需要持久化全局事务状态。数据持久化由数据节点保证，全局事务状态持久化由GTM保证。

4.GoldenDB保证一致性（C）

本节将探讨GoldenDB是如何从技术上保证一致性的。

（1）保证事务一致性。

为保证分布式事务一致性，业界主要有两种方案：两阶段提交（2PC）与最终一致性（EC）。两阶段提交存在同步阻塞、一致性读隔离级别下脏读问题；最终一致性方案实现代价高，处理逻辑复杂。

分析业界上述方案的优缺点后，GoldenDB设计出基于全局事务ID（简称GTID）的分布式事务一致性方案。该方案把协调者（Coordinater）和全局事务管理（GTM）两个功能分开。GTM仅管理全局事务状态，由计算节点（DBProxy）充当协调者。GTM支持本地持久化与备机同步，确保全局事务状态信息不丢失。

GTID方案的核心思想，是在全局事务提交过程中，发生部分节点提交失败时，回滚已提交节点数据，而不进行提交失败重试，保证数据最终一致性同时解决同步阻塞问题。

（2）保证数据一致性。

在分布式环境下，数据被打散并存放在多个数据节点上，不但要保证单一数据节点数据一致性，而且要保证所有数据节点数据的一致性。GoldenDB为此设计出集群（Cluster）、分片（Group）、工作组（Team）与高低水位（HLWM）的概念。

在分布式数据库系统中，最大的逻辑单位被称为集群，一个分布式数据库系统可以同时存在多个集群。每个集群由多个分片组成。按照两地三中心部署，每个分片又由最多3个工作组构成。每个工作组由实际的数据节点组成。

分片内使用快同步功能组建主备复制关系，分片内部只允许存在一个主节点。主节点所在工作组被称为本地工作组，负责对外提供服务。其余从节点所在的工作组被称为同城工作组或异地工作组，负责同步主节点数据和主备切换。

主从节点数据同步时，从节点未完成数据同步之前，主节点事务无法完成提交操作，强迫从节点与主节点数据保持一致。但从节点数量越多导致主机事务提交越慢，因此，可以通过高低水位与响应数的设置来进行控制。既能保证从节点数据一致性，又能避免提交过慢的问题。

高低水位分为高水位与低水位两个指标，其功能作用于工作组上。按照本地、同城两个工作组说明，高水位要求两个工作组同时满足数据一致性要求，否则会触发告警。低水位要求两个工作组至少一个满足数据一致性要求，否则整个分片数据只读。

响应数功能作用于工作组内，即使工作组中存在多个数据节点，通过设置响应数，可以控制工作组内满足数据一致性要求的数据节点数量。从而避免由于从节点过多，导致主节点事务提交变慢的问题。

（3）GoldenDB快同步。

MySQL异步复制存在缺陷：在主备切换的时候无法保证备机的数据和主机完全一致。

MySQL在异步复制的基础上提供了一个半同步插件，要求必须收到一个备机的应答响应才让事务在主机上提交，当备机应答超时的情况下，半同步会自动退化成异步模式。该方案在主机本身无故障的情况下，能保证不丢失事务，一旦退化成异步复制就回到上面的问题上去了。

GoldenDB采用了快同步方案：针对半同步进行优化处理，增加了线程池处理逻辑；优化了半同步等待备机响应处理流程和事务提交机制，新增了组管理机制和高低水位阈值机制。

GoldenDB快同步方案，备机超时不会退化为异步，而是通过高低水位设置产生错误码告警。

5.GoldenDB保证分区容错性（P）

在分布式环境中，涉及的组件众多，由于环境比单机环境复杂，根据不同组件可分为数据节点、计算节点、GTM节点和管理节点。

数据节点容错性。在分布式环境下，事务执行中发生主节点异常，未提交数据不会被同步到从节点。若出现部分提交，则进行已提交事务回滚。之后进行主从切换，在从节点切换成主节点之前，该分片不提供读写服务，主从切换完成后自动恢复。

计算节点容错性。计算节点本身无状态，发生异常仅导致当前业务失败，并且负载均衡自动屏蔽该节点，保证后续交易发往其他计算节点。对于需要进行已提交事务回滚的事务，计算节点故障无法执行。计算节点部署的监控会重启进程，执行回滚操作。若计算节点重启失败，则根据配置由其他计算节点发起对等回滚操作。

GTM容错性。GTM按照主从部署，通常采用一主多从模式。主机异常时会自动触发主从切换，在从节点切换成主节点之前，不提供申请释放GTID服务，主从切换完成后自动恢复。

管理节点容错性。管理节点分为管理组件与集群元数据两部分，通过部署双机HA软件搭建主从关系，管理组件安装在主从服务器上，集群元数据存储在元数据库中。若主机管理组件发生故障，双机软件会自动切换到从机。若元数据库发生故障，双机软件会自动切换到从机，并完成主备切换操作。

6.GoldenDB最大程度保证可用性（A）

在分布式环境下，当服务器、网络出现故障时，为保证一致性，数据库服务会不可用，导致可用性下降。在无法完全保证可用性的情况下，需尽可能缩短系统不可用时间，GoldenDB通过主从切换、HA切换自动恢复系统可用性，通过高低水位设置能最大程度保障系统的可用性。

低于高水位会有告警，低于低水位会触发只读。系统可用性会有一个从正常到异常告警，再到异常不可用的一个衰减过程。如能及时响应告警、处理故障，可以保证较高的系统可用性。

银行传统上使用的Oracle、Db2等商业数据库，都属于集中式架构。集中式数据库安装在单台服务器上，供本地用户和远程用户访问。

1.和传统集中式数据库的区别

较传统集中式数据库，性价比更高；整体性能优于传统集中式数据库；集中式数据库通常选择IBM小机，IBM小机可靠性高，分布式数据库组成x86服务器集群提升可靠性；集中式数据库通常纵向扩展（增加CPU个数、增加内存），分布式数据库可以纵向与横向同时扩展。

2.分布式数据库特点

扩展性：能够按照需求变化进行动态伸缩，支持横向与纵向扩展。

可靠性：不存在单点，服务不会因为单点失效问题而中断，切换机制要更丰富、整体容灾能力更强，数据可靠性、服务可用性有较高质量的保障。

高性能：由多台物理服务器组成，性能与数量成正比，基本呈线性增长。

3.分布式架构带来的局限性

分布式数据库带来了数据去中心化、负载分摊的优势，同时也带来了某些局限性。不单需要从架构上解决，还需要通过应用和规范来解决。

（1）分布式架构带来的复杂性，比集中式数据库运维难度大。解决方案：通过平台化运维的新思路，统一上报告警及统计信息、统一日志中心、自动化监控、自动化运维、自动化巡检等。

（2）X86服务器可靠性低。解决方案：服务器和数据都进行冗余配置，当出现节点故障时，通过主备切换保证服务的持续可用性。

（3）应用设计复杂度高。解决方案：设计层面需合理设置分发键、增加冗余字段、减少多表关联、尽可能减少跨节点交互。

（4）分布式事务一致性维护成本高。解决方案：分布式依赖网络，网络问题会导致事务一致性提交时间变长，因此应用编写的SQL语句应尽可能带分发键，减少跨节点事务数量。

从集中式数据库转型到分布式数据库后，需要关注设计开发和运维方面带来的新问题。

1.设计开发方面

设计开发方面主要涉及SQL兼容性问题、性能问题、异地一致性问题等。

SQL兼容性问题。GoldenDB完全兼容MySQL语法。但部分语句在分布式环境下执行代价过大，通过产品迭代，完善执行效率、逐步放开代价过大的SQL语句功能。

性能问题。由于数据切分到多个数据节点，涉及网络通信的交互次数和交换的数据量较多时，存在SQL语句性能慢、锁冲突、多分片访问不均匀问题，需要采取针对性的优化方案。

异地数据一致性。由于网络时延、网络带宽等问题，异地数据可能存在一致性问题。异地对外提供服务前，分布式数据库会进行业务数据一致性对齐，自动恢复到最新的一致性时间点。

2.运维方面

运维方面主要涉及用户安全问题、数据安全问题、扩展性问题等，具体如下：

用户安全。分布式数据库中涉及多种用户，包括Linux操作系统用户、数据库用户，对这些用户如何进行管理是个难题。需要按照相关规范控制用户权限：

数据安全。数据的安全问题是重中之重，从设计、部署到日常运维均需要保障。

扩展性。扩展性包括纵向扩展和横向扩展，纵向扩展增加硬件，横向扩展增加数据分片。横向扩容之后需要重分布，重分布之前规划磁盘空间，确保空间足够。

运维中的性能问题。通过监控及时发现性能问题并进行优化。

监控问题。分布式数据库组件众多，通过单一种类的监控定位问题比较困难，需要一套或者多套监控体系配合来精准定位到故障节点。

巡检问题。需要开发一键式巡检脚本，通过生成的巡检报告展示分布式数据库运行趋势，从而配合监控更早定位出问题。

备份恢复问题。对数据备份和一致性恢复要求高，目前使用NBU软件进行备份恢复。

读写分离问题。为了提升交易处理的吞吐量，将读操作分流到备机。

自动化应急。分布式数据库涉及的组件多，必须实现自动化应急，真正做到“预防为主，处置高效”。