关于数据库:分布式数据库-GaiaDBX-金融应用实践

1 银行新一代外围零碎建设背景及架构

在银行的 IT 建设历程中，尤其是中大行，大多都基于大型机和小型机来构建外围零碎。随着银行业务的疾速倒退，这样的系统对业务的反对越来越举步维艰，次要体现在以下四个方面：

• 首先是难以反对银行疾速倒退的业务。随着国内电商、互联网领取、手机领取的迅猛发展，银行的交易量呈现指数级的增长。比方咱们的某银行客户，以后每秒的交易量峰值在一万多左右，预计在将来几年会逐步增长到每秒 6 万笔交易，而且后续还会持续增长。在这种状况下，基于大型机的集中式架构，单纯靠硬件的升配，曾经无奈反对业务的持续增长。
• 第二是难以匹配银行零碎的迭代更新速度。原有的基于大型机的胖外围架构，迭代周期往往在数月甚至半年。但随着银行间、以及银行与互联网金融企业之间的竞争加剧，银行迫切需要疾速推出新业务进行翻新，他们也心愿可能像互联网公司那样，可能按周级进行疾速迭代，疾速响应业务需要。
• 第三是零碎危险。银行业迫切需要做到软件及硬件的自主可控。
• 第四是生态关闭。大型机技术倒退慢、人才难招。当初再去里面招一个懂 IBM 大型机的人曾经很难了。

因而，在国家现有政策的疏导下，各大银行最近几年都在做一个事件：把原有的外围架构从大型机下移到传统的通用服务器架构上，并建设一套自主可控的新技术体系，简称外围零碎下移。

在进一步了解银行零碎之前，咱们先理解下银行客户的业务体量、业务需要以及外围系统对业务反对状况。以一个国有大行来举例：它的客户量在 5-7 亿，有 10-20 亿账户，在全国有 2-4 万个网点。从每秒峰值交易量来看，约为每秒 5-8 万笔交易。

具体到数据库层，反对以上业务还须要联机交易系统，例如存贷汇业务。数据库层最大的表有百亿级记录数，TPS 达到百万级。此外，对立查问业务要求反对近十年交易明细的查问，即万亿级的查问记录数。即便放到互联网公司用的通用服务器，也是须要上千台服务器能力撑持相干业务的发展。

通过以上的介绍，大家能够发现，银行客户的业务体量和数据量曾经达到了大型互联网公司的量级。如果想把这个零碎从大型机下移到通用服务器架构，那么原有的集中式架构必定是无奈满足的，必须像互联网公司一样采纳分布式架构。

因为银行有和大型互联网公司相近的业务体量，因而在技术体系上，也借鉴了互联网公司的技术体系。

从 IaaS 层来看，银行采纳了 X86、ARM 架构的通用服务器，也用到了混合云技术，大量应用了虚拟机与容器服务。

在 PaaS 层，银行应用了大量的分布式系统，如开源的微服务框架（例如 SpringCloud），以及开源的或者商业的数据库，包含分布式 / 单机 / 关系型 / 缓存型的数据库，以及日志数据库 ES、时序数据库等。在中间件层，也用到了大量的开源的或者基于开源革新后的组件，例如音讯队列、对象存储、分布式锁等。

在 SaaS 层，银行次要通过单元化 + 微服务的架构来实现分布式扩大。银行将本身业务利用划分成三种单元。

• 最上层是全局单元，次要是起到全局路由及流量散发的作用。
• 第二层是业务单元，外围的业务逻辑都在该局部来实现。同时，为了实现业务的横向扩大并反对数亿客户量，银行业跟互联网公司一样，对业务进行单元化拆分。例如咱们接触到的某银行，就是将本身的业务拆分为了 16 个业务单元，每个单元五千万客户，16 个单元部署在两个机房造成同城双活的架构。
• 最底层是公共单元，一些不太好或没必要做单元化拆分的利用，放在公共单元提供公共服务。

通过上述剖析能够看到，在新一代银行外围零碎外面，整体的架构体系曾经和互联网公司很靠近了，大家用的都是雷同的技术栈，只是服务的业务场景不同。在将来，银行业跟互联网业的技术交流会进一步严密，人才的流动也会进一步频繁。

在业务采纳了单元化划分后，数据库的架构是怎么样的呢？目前在银行的新外围零碎下移中，次要采纳了以下两种数据库架构：

第一种是单机数据库架构。这种数据库架构比较简单，故障域较小，但相对来说业务零碎会比较复杂。因为有些模块，如全局路由模块，是全局的总入口，没法做单元化拆分。因而一组单机数据库无奈满足性能与容量需要，仍然须要在业务层做数据拆分。除此之外，单机数据库无奈齐全反对业务单元层的业务落地。后面提到，咱们接触到的某银行一个业务单元要承当五千万的客户数，一组单机数据库仍然无奈反对。于是在业务层进一步拆分为 4 组数据库共 64 张子表，业务层须要去解决大量的拆分及分布式事务相干的业务逻辑，整体就更简单了。

另外一种是分布式数据库架构。这样的数据库外部架构尽管更为简单，但它能够提供更好的性能。对业务层来说，一个单元采纳一组数据分布数据库即可，业务层的逻辑就更为简略了。

因而咱们认为，随着分布式数据库的逐渐成熟与利用逐步宽泛，业务单元化 + 分布式数据库会逐步成为风行的银行业务架构。

综上，银行外围零碎在下移的场景下，对数据库在如下几个方面提出了要求：

• 第一是分布式扩展性。因为采纳了通用服务器，它的单机性能要远弱于大型机或者小型机。在这种状况下，数据库须要具备分布式可扩大的能力来满足上亿客户的金融需要。
• 第二是强一致性。金融场景对数据正确性、一致性的要求极高。因而要严格保障对事务的 ACID 个性。否则，业务层就要做大量的工作。
• 第三是容灾能力。通用服务器在硬件故障率方面要比大型机、小型机高很多。因而须要咱们的数据库有更为牢靠的可用机制以保障 SLA。同时，监管对于容灾能力的要求也在一直晋升。比方，对于新建设的外围零碎，监管要求必须满足 5 级以上的容灾能力，且满足同城双活并保障 RPO 为 0。在具体执行上，监管的要求也越来越严格，比方同城双活，之前是只须要具备相干的技术计划即可，但当初每年人行的监管都会间接到现场，要求做机房级实战故障切换。
• 第四是运维能力。零碎下移到通用服务器并实现去 IOE，数据库节点数量要呈现 50 倍的增长。以咱们的一个银行客户举例，从小型机下移后，数据库节点数从 20 增长到 1000（当然这外面也预留了几倍的性能增量）。在和客户的交换过程中，他们也认同这个观点，认为零碎下移后，节点数要增长一到两个数量级。但运维的人力不可能因而减少几十倍，在这种状况下，就要求咱们的运维效率要有质的晋升，须要可能智能化、自动化去做相干的运维工作。

2 分布式数据库 GaiaDB-X 的金融场景计划

接下来咱们分享第二局部，分布式数据库 GaiaDB-X 针对金融场景的解决方案。

GaiaDB-X 数据库是百度智能云研发的 Shared Nothing 架构的分布式数据库，它能够基于通用服务器做横向扩大，来满足高性能、大数据容量的需要。

总体来看它分为计算层、存储层、元数据三层架构：

• 计算层是无状态、可横向扩大的一层。它对外兼容 MySQL 协定，接管到 SQL 申请后，再通过 SQL 解析、权限查看、逻辑优化、物理优化之后，生成 DistSQL 下发到各个存储层的分片。为了达到更好的性能，逻辑与物理上尽量将数据过滤及计算能力下推到存储层，收到后果后，再把数据进行聚合计算，最初返回给客户端。
• 计算层的上面是存储层。它采纳多分片的形式进行扩大，数据依照肯定的分片规定打散到了各个分片中。咱们反对 Hash、Range、List 等分区形式来做数据分区。同时，分片内数据采纳多正本的形式来保障可靠性。
• 第三是 GMS 节点，即全局元数据管理模块。它用来治理全局性数据，例如表的 Schema 信息、权限信息、表的路由信息，还有前面要介绍到的用于做分布式事务的全局逻辑序列号。GMS 也采纳多正本的形式，采纳 Raft 协定进行数据同步。

在最底层是咱们的对立数据库管控平台，来实现对数据库集群的治理。比方在百度团体外部数十万的数据库节点，都是由该管控平台来治理的。

GaiaDB-X 数据库是百度团体倒退历史最久、利用最宽泛的一款数据库，到当初为止已有 18 年的倒退历史。它的倒退也与百度的业务倒退非亲非故，大略能够演绎为四个阶段：

• 第一阶段是从 2005 年开始，为了满足搜寻、社区业务中大量读申请的场景，咱们通过一主多从的集群化外加读写拆散来扩大读性能。
• 第二阶段是为了反对凤巢广告零碎与百度网盘，满足它们对万亿级数据量的需要，咱们开始做分布式系统。到了 2014 年，咱们就曾经在凤巢广告零碎中替换了基于 Oracle 的盘柜，为凤巢每年节俭了上千万的老本。针对百度网盘，咱们有个 3000 台服务器的集群反对网盘业务，所有网盘文件的元数据信息都存储在这里，最大的表白到万亿级记录数，至今仍是国内最大的关系型数据库集群之一。
• 第三阶段是随着百度钱包等泛互联网业务的衰亡，对数据的一致性要求更高了。因而，咱们实现了分布式事务强统一的个性，保障金融数据的正确性。
• 第四阶段，也就是当初。随着百度智能云对外技术输入，咱们曾经把数据库输入到了十余个行业，笼罩 150 家客户。在金融行业，GaiaDB-X 曾经承接了金融外围业务，包含百信银行、银联商务、某交易所及国有行等。

对于分布式数据库，程度扩大能力是其外围能力。除了在计算层与存储层做程度扩大外，咱们还要着力去解决影响咱们扩大能力的单点。

第一个是 GMS，即全局元数据模块。因为它要提供一个全局递增的全局逻辑时钟，每一次事务都须要调用它。为了防止其成为瓶颈，咱们采纳批量预调配的形式来晋升其总吞吐，在此模式下，其每秒可调配 1200 万个 TSO 序号，远超出百万级 TPS 的需要。

第二个是全局事务表。为了保障分布式事务的原子性，咱们须要将正在进行中的事务保留到一张全局表中，因而它的性能也会间接影响到全局性能。咱们采纳自治理的形式，将全局事务表做成分布式表，分布式地存储在集群中，这样就能够实现分布式扩大。

在理论利用中，比如说像 19 年的春晚抢红包，咱们反对了三亿用户抢红包，撑持了峰值达每秒 12 万交易量。除此之外，针对某银行领有 8000 万账户的外围账务零碎，咱们也安稳反对了其 6 万每秒的 TPS，充沛验证了 GaiaDB-X 的程度扩大能力。

除分布式外，咱们也反对单机场景，实现了单机分布式一体化。为什么须要单机分布式一体化呢？以咱们的一个银行客户来说，全行的业务零碎有 200 多个，其中大部分零碎（大略占 70% 左右）对性能与吞吐的要求并不高，一组单机数据库就可能满足其业务需要。但对于剩下的 30% 业务，它对性能的要求是单机数据库无奈满足的，须要分布式数据库来满足其扩展性。

因而咱们通过一体化的形式，来满足银行不同体量的业务对于数据库的需要。同时，咱们也具备单机数据库扩大为分布式的能力，在对应业务的数据量增长后，可能扩容为分布式。

扩展性的另外一个目标是主动做数据拆散。在金融场景外面，存在多个业务共用一个数据库集群的场景，比方业务分为联机交易系统与查问类零碎，数据库便对应划分为交易库和历史库两个。

对于交易库来说，只保留联机交易会频繁应用到的数据。例如账务后果数据及当天的交易记录，以满足对交易业务的疾速响应。对于查问不那么频繁的即时交易记录，这可能就是一个相当大的数据量，个别都能达到千亿甚至万亿级别。这时，咱们就能够将这个数据主动转移到历史库下来，用更高密度的存储机型来存储。一方面能够升高硬件老本，同时也能够防止对联机业务的影响。

这样做对业务来说，对外出现的是一套数据库，业务能够依据须要来解决不同数据分区的逻辑，也不必在多套库之间通过 DTS 做数据同步。同时还把交易数据和历史数据做拆散，以保障对联机业务的性能，同时也满足了查问业务的查问需要，防止其相互影响。

在金融场景中，对事物的 ACID 个性有着严格的要求：

• 持久性。指的是事务一旦提交就不会失落，个别通过多正本 + 强同步来解决。
• 原子性。一个事务要么全副提交，要么全副回滚，不存在局部提交的状况。通常，数据库的 XA 协定，通过两阶段提交能解决这个问题。

然而 XA 协定不能很好地满足一致性与隔离性。以简略的转账场景为例，A、B 原来各有 100 块钱，总共 200 块。而后 A 给 B 转账 50 块钱。此时，咱们会先给 A 扣 50，再给 B 加 50。如果通过 XA 协定来做的话，先走 prepare 再 commit，咱们能够看到，commit（图中第 7、第 8 步）过程不是原子过程，存在一个执行时间差。在这个时间差内，另外一个事务去读取数据，就可能存在读到提交了一半的数据，A 和 B 的总和是 150 而不是 200。这是 XA + 2PC 解决不了的问题。

为了解决这个问题，业内个别是引入一个全局时钟来做一致性的保障。通常有三种实现形式：

• TrueTime 计划。这个是大家比拟相熟的计划，Google Spanner 也发过论文。但它的缺点是依赖硬件，要引入 GPS 与原子钟，这个一般来说是难具备的。
• HLC 计划。采纳该计划的典型数据库系统是 CockroachDB，它的长处是不依赖硬件，而且是去中心化的。然而毛病也很显著，一致性比拟弱，而且要求服务器间的时钟误差不能超过 250ms，否则就无奈失常运行。
• TSO 计划，比方 TiDB 就是采纳了这种计划。TSO 实质上来说是一个全局惟一而且自增的逻辑序列号，一个事务在开始时与事务 commit 时须要两次找 GMS 获取序列号，而后把 TSO 号作为版本号提交到存储层，存储层的 MVCC 机制来判断数据是否可见。它不须要硬件具备强一致性，但毛病是依赖一个全局核心的时钟分配器 GMS。但这并不是一个问题，因为刚刚咱们也提到了，尽管 GMS 不具备扩展性，1200 万的 TPS 曾经齐全满足业务的惯例须要了。因而咱们最终采纳了这种计划。

除了保障事务的一致性外，咱们还须要保障上下游零碎的数据一致性。在开始之前，咱们首先要讲一下银行的典型业务场景，它个别分为三个子系统：

• 第一个是联机交易系统，例如存取款、在线领取等。这个零碎的并发量高、提早敏感，间接影响到用户体验。
• 第二个是跑批类的业务零碎。例如结息，每天晚上中午计算前一天的利息。这些业务是后盾业务，有大量的读取与计算操作，提早不敏感，然而对数据一致性要求高。怎么可能让这样的业务尽量避免对在线业务的影响，同时又可能读取到最新的数据呢？咱们的形式是让跑批业务去读取从库数据，从而防止对主库的性能影响，同时联合 TSO，即全局逻辑时钟的对位对齐机制。等到从库水位追齐之后，才返回读取数据。当然这会引入肯定的延时，然而因为跑批业务对响应延时不那么敏感，所以是能够承受的。
• 第三个子系统是大数据类的离线业务。通常来说，就是银行外部的各种大数据、数仓等零碎，须要把数据库的数据同步过来。这样的业务对实时性要求不高，但要求最终的数据是统一的。因为各个计算节点都会承当流量，也会生成 BinLog。因而，如何对多份 BinLog 进行排序，让它们可能严格放弃时序是咱们须要解决的问题。咱们的全局 BinLog 有两个模块，一个是 pump，从各个 CN 节点抽取 BinLog，而后在 Sorter 节点基于 TSO（全局逻辑时钟）进行排序，来保障造成一个全局时序正确的 BinLog，以保障这个离线零碎收到的数据的最终正确性。

接下来咱们看一下容灾能力，除了对单机故障的容灾之外，还有对特定机型的容灾。因为银行把零碎下移到通用服务器，通常都是通过两阶段来施行：第一阶段是下移到 X86 的 CPU 芯片上，这个过程银行、互联网厂商都肯定的教训。第二阶段是要实现服务器芯片的根本国产化，就是说应用国产的鲲鹏、飞腾或海光 CPU 芯片，这方面大家都是在探索性的发展相干业务。

以百信银行举例，它与其母行中信银行一样，抉择了基于鲲鹏做国产化的路线，而且在业内比拟超前。相较于其余银行仅在周边零碎或者数据库从库来做国产化，百信银行的周边业务跟外围零碎都和主站一样基于鲲鹏服务器来做，这个在业内是较为当先的。

为了保障客户业务零碎实现平滑的国产化，咱们在产品上实现了一库多芯的计划，次要资源池基于鲲鹏，但搁置了一个独立 X86 资源池，在技术上实现托底，同时也可能将原有换下来的服务器可能利用上，防止资源节约。

依据人行的监管要求，银行外围零碎个别要具备 5 级以上的容灾能力，这就要求具备两地三核心的容灾能力。

下图是咱们客户的一个典型机房部署架构。首先在北京有两个同城机房，其物理间隔在 50-100 公里左右，网路提早在 1ms 左右。同时还有一个异地机房做灾备，物理间隔个别是 1000 公里左右，比方合肥，网络延时是 10ms。

同城两个机房业务做双活部署，同时承受业务流量。数据库在两个机房采纳 3 + 2 的部署模式，机房间采纳强同步的形式来保障在产生机房级的故障之后，数据库能进行故障切换，而且保障数据的 RPO 为 0。

为保障单机房故障后的零数据失落，咱们采纳分组强同步的形式，将 id1、id2 各划分一个复制组，复制组间采纳强同步的形式。每个复制组保障至多有一个正本接管到数据之后才返回胜利。这样在容忍多数正本故障的同时也可能保障单个机房故障后的零数据失落。

异地机房的指标是当北京的两个机房都呈现灾难性的事件之后，可能降级实现外围业务。它采纳异步级联的形式来同步数据，首先异步是为了防止阻塞对主地区的数据库写入；采纳级联形式，没有跟主地区机房造成复制组，次要一个为了放弃灾备机房的数据库的拓扑独立性，缩小依赖，保障在关键时刻可切换，另外也是升高跨地区同步的数据量，只须要同步一份数据即可。

联合在多家金融客户的实际，咱们和中国信通院一起公布了金融数据库的容灾技术报告《金融级数据库容灾备份技术报告（2021 年）》。大家能够在公众号后盾回复「金融级数据库容灾备份技术报告」获取。

最初一部分是运维能力。外围零碎下移及国产化的背景之下，数据库系统出现两个变动：

一是数据库的节点数呈现了 50 倍的增长，这外面既有技术架构的起因，也有数据库预留了肯定的性能空间的起因。

二是数据库的品种也变多了。对于银行零碎来说，之前根本就是抉择 Oracle 或 DB2。当初则开始应用多种开源数据库和国产数据库。除此之外，为了防止像之前一样被繁多厂商绑定，银行也会特意抉择多家数据库厂商，在这种状况下，对银行的运维的挑战就更大了。

因而，联合百度团体及百度智能云治理大规模数据库节点方面的教训，咱们将 GaiaDB-X 数据库云管平台进一步泛化，造成了具备治理多元数据库能力的对立平台，它除了可能治理 GaiaDB-X 本身，也能治理其余的开源数据库。通过帮忙银行建设企业级的 DBPaaS 治理平台，进一步晋升了银行的运维效率。

3 金融利用案例介绍

接下来，我来分享百度智能云在金融方面的一些典型案例。

首先是百信银行。它的特点是齐全去 O，是一家齐全没有 Oracle 的银行。全行 200+ 业务零碎，无论是外围账务零碎还是周边零碎，简直全副是基于 GaiaDB-X 数据库来构建的，至今曾经安稳运行五年。

按数据库节点数计算，百信银行目前的数据库国产化率达到了 99.93%，遥遥领先于行业平均水平。

同时，百信银行在容灾和国产化畛域也比拟当先，在 2019 年就实现了全行次要零碎的同城双活建设，2022 年开始将全行业务逐渐迁徙到基于鲲鹏的国产云上，进而实现了全栈的国产化。

在硬件老本方面，咱们通过采纳通用服务器来代替 IOE 硬件，帮忙百信银行的单账户均匀硬件老本升高了 70% 以上。

下图是人行上面直属的某交易所。因为是波及到国家金融稳固，所以在外围零碎上须要逐渐解脱对 Oracle 的依赖，并领有两地三核心的容灾能力。

因为以后的一些数据库都不能满足他们的业务场景需要，因而该交易所和百度采纳了联合开发的模式，共建数据库能力。在两年的单干过程中，咱们从外围的信息管理系统动手，逐渐深刻到外围交易系统，再到离线库数据分析系统，进而逐渐实现数据库国产化。

此外，因为交易所的交易系统对低延时的要求较高，同时基于容灾要求又有同城双活的要求，如何在跨机房的状况下保障交易延时就成了亟待解决的问题。因而咱们独特建设了 Collocate 机制，来尽量减少跨机房数据的拜访，最终将交易延时从 80 毫秒升高到了 15 毫秒。

下图是国内某国有大行客户。他们在最近两年把原有的基于小型机的外围零碎下移到了通用服务器中，数据库也从 Oracle 代替为了开源单机数据库。

但在这个过程中，该行面临两个问题：一是数据库节点数增长了 50 倍，服务器数量达到了 1000 台左右，如何做好数据库的自动化部署、上线变更、版本升级、参数治理、性能诊断等工作。二是如何联合业务的单元化，造成业务与数据库的同城双活与异地容灾能力。

借助百度智能云提供的对立数据库管控平台的能力，历时两年，咱们与客户一起实现了新外围零碎的全面投产，也顺利通过了人行的验收。

以上是明天分享的全部内容。

——————END——————

举荐浏览

云上业务一键性能调优，应用程序性能诊断工具 Btune 上线

一文详解动态图和动态图中的主动求导机制

千万级高性能长连贯 Go 服务架构实际

百度搜寻 Push 个性化：新的冲破

百度智能云千帆 AppBuilder 构建 AI 原生利用开发新范式