作者Dingk·2020-06-13 14:28

副总经理·张家港行

银行核心业务系统分布式数据库选型的典型问题

字数 7124阅读 3697评论 1赞 8

**一、前言**

银行传统核心业务系统（以下简称：核心系统）是银行系统的心脏，数据库通常采用集中式IOE架构，系统运行稳定，但软硬件供应依赖国外少数厂商，建设和维护成本较高。国产分布式数据库近年发展迅速，在互联网金融领域应用已经成熟，已经在国内不少银行的互联网核心和信用卡核心落地，但是由于核心系统交易多而复杂，是各银行最重要的系统，将分布式数据库适配到传统核心系统的技术难度和风险巨大，国内当时还没有成功落地经验可借鉴，各银行都很慎重。

张家港农商行通过一年多的探索验证，在2019年8月18日上线的新核心系统中采用了国产分布式数据库，期间克服了适配性改造难题、人才梯队建设难题、后期开发和运维难题、主备数据库和分布式事务一致性保障难题、平台整体不可用等其他未知难题以及最难的决策难题等困难，最终新核心系统顺利上线，新核心系统上线至今平稳运行9个月，系统负载均在10%以下，各项运行指标均表现优异 。

下面是 张家港农商行在核心建设过程中分布式数据库选型的过程，遇到的困难和解决方案，可以帮助各银行在核心交易系统分布式数据库选型过程中提供一定经验和帮助。

二、 **典型问题**

**【问题1】张家港行是核心全部上了腾讯的TDSQL吗？**

整个核心系统 已 全部 使用 TDSQL 。涵盖了银行特有的切日、结息、计提、批量、多法人等业务场景，承载着存、贷、汇、银行卡、结算、客户开户、存款产品、计费等主要业务和产品的交易处理。以及全部的会计核算 。

核心系统在这次重建中并入了信贷核算系统、电子账户系统（互联网核心）。

**【**问题**2**】****张家港行为何选择TDSQL？****

作为银行的核心系统，对数据库的选择，有一点特别重要，就是数据库厂商的实力。如果只是一些小的外围系统进行尝试，选择任何一个数据库都不会有什么问题，这也是绝对不考虑无厂商支持的开源数据库（纯MYSQL、POSTGRESQL）的原因。

我行老核心采用的是SYBASE 数据库，最开始的版本是 SYBASE 12.5 ，中间不断地进行版本升级与优化，把 SYBASE 数据库的性能发挥到了极致，而 SYBASE 数据库目前已经不是主流了，性能已经无法满足我行业务发展需求，而且问题定位这一块主要靠经验，看日志等，监控展示手段有限，所以此次新核心系统升级，必须将 SYBASE 数据库进行更换，

面临着数据库的选型，因为无论将SYBASE 升级到像 ORACLE 这种传统集中式数据库还是分布式数据库，都是巨大的变化，都要面临巨大的挑战和风险。而分布式数据库能提供的大并发弹性扩展功能，且已经在银行互联网核心应用成熟，目前多个银行都在探索并已经在互联网核心落地，可以看出这是未来的一个趋势所在。所以考虑尝试使用分布式数据库。

当 时国内的关系型分布式数据库产品非常多，可选择的也很多，我们首先对国内分布式数据库主流厂商数据库产品进行了多轮次深入的技术交流，例如腾讯TDSQL 、阿里蚂蚁金融 OceanBase 、华为 GaussDB 、热谱 HotDB 以及京东云数据库等国内主流适合做实时交易的 OLTP 型数据库。

我们对微众银行核心和南京银行互联网核心建设进行了现场调研，学习建设经验和遇到的问题。

在对各个厂商的技术有了深度认识后，我们选择了腾讯TDSQL 和阿里 OceanBase 两款分布式数据库产品进行 POC 测试。 最后 综合考虑选择了TDSQL。

**【问题3】分布式数据库TDSQL、OceanBase 的 POC测试的关注点有哪些？**

直接列举关注点：

1. 基础的增、删、改、查语句的性能

2. 分布式事务的多表更新性能

3. 分布式事务的增删改查混合性能

4. 数据库多种表（分片表、单表、广播表）特性验证，数据分片原理了解

5. 常用数据库语法的兼容性（函数、分组、limit等等）

6. 表关联查询的支持程度

7. 死锁检测（非常关键）

8. 分布式事务的ACID实现验证测试

9. 分布式事务的全局数据一致性验证测试

10. CAP的实现情况

11. 主备数据一致性的验证测试

12. 备份恢复的数据一致性

13. 数据库分片扩展测试

14. 高可用的简单测试

**【问题4】贵行选择了哪些分布式数据库，分别用在哪些场景，分布式数据库选型时，要注意哪些方面？**

我行的大数据平台采用了华为的大数据平台，主要用于 历史 数据 存储、大数据 分析。

交易系统仅采用了TDSQL一种分布式数据库。

使用分布式数据库的 应用系统主要有

1、 核心业务系统

2、 ECIF

3、 中间业务

4、 统一移动 开发 平台

5、 2020年以后所有新建系统

分布式数据库种类很多，有NOSQL、NEWSQL、还有基于Hadoop的平台，一般都会只侧重OLTP、OLAP中的一个方面，NOSQL 放宽了ACID原则，采取最终一致性原则， NEWSQL在这方面进行了加强，相对传统数据库， 更多只是 功能有些限制，事务的ACID能得到 非常近似的 保证 。

数据全 局（所有分片节点） 实时一致性方面 仍 需要具体验证。

另外，分布式数据库，分片表的内部分库策略也非常重要，会影响应用的设计思路，及优化方法。

**【问题5】NewSQL有两类：基于分库分表的数据库访问中间件和原生分布式数据库，贵行在数据库选型时，选择了数据库访问中间件的TDSQL，是基于哪些方面考虑，有考虑过原生分布式数据库吗？**

TDSQL的实现模式类似访问中间件，但和一般的中间件实现分库分表还是存在比较大的差别的。可以这么比喻，TDSQL的设计，在数据存储引擎上，直接选择 了 MYSQL的innodb引擎，但其它设计，远较一般的中间件实现要复杂。

阿里的OceanBase， 其 存储引擎也是原生自主开发的。

两者比较， 后者受限更少 ，但需要测试验证的内容也 更多 。

现阶段 ，提供给用户的数据库能力是类似的 。

**【问题6】银行核心上分布式数据库的实践中有什么需要特别注意的吗？**

金融行业的核心是非常重要的系统， 使用国产分布式数据库 是一个非常需要慎重的选择。张家港行 在 核心改造的过程中，有什么特别需要注意的地方吗？在架构设计方面有什么最佳实践吗？

首先 需要有充足的准备，充分的论证，厂商的充分支持。

厂商的支持非常重要，不管是应用厂商还是数据库厂商。现阶段应用分布式数据库，改造工作必不可少，需要能够及时的发现与解决问题 。

银行自己的科技团队，也需要真正投入项目之中，需要真正了解分布式数据库的所有 相关 特性， 知晓 其仍存在的问题 。 在改造中要始终主导项目，做好系统改造的工作，以及测试验证工作。

我行采用的方式是找专业的团队做专业的事，找应用的厂商做应用，找数据库的厂商做数据库，最关键的是由行方、应用厂商、数据库厂商组成技术攻坚小组，专门解决各类改造过程中的问题，也能达到培养行方开发和运维人员的目的。

下面列举具体要注意的技术问题。

分布式数据库，目前基本都不支持存储过程，对于复杂SQL的查询，也有限制。应用分布式数据库和应用的架构关系不是很大，集中式、分布式、微服务模式都可以。但应用需要设计成，在和数据库的交互方面，以简单SQL为主。复杂的逻辑，由应用完成。总的原则就是尽可能让 SQL 语句限制在同一个数据节点内，减少跨节点数据关联查询。

然后就是对数据库的了解，尽可能的详细的进行POC测试，提前对数据库在分库分表、分布式事务、死锁检测、SQL支持、关联表查询限制、性能 、开发标准 等有全面的了解 ，用于指导后续改造工作 。

系统改造的过程主要有兼容性改造（函数、语法），性能优化，准确性验证、稳定性验证、 高 可用验证这几个部分，部分过程可以并行展开。

兼容性改造是难度最大以及最需要资源投入的部分，但是难度不高，工作量比较大，通过改造，先将应用跑起来。

性能优化改造过程是从简单到复杂，我们是先从高频交易入手，集中处理与高频交易相关的业务以及子系统，然后是跑批类交易，跑批与高频交易相比，SQL 相对复杂冗余但是占总交易类的比重较低。解决了高频交易其实就已经解决了大部分匹配问题，我行在这个过程中积累了丰富的调优经验，这些经验再应用到其它业务系统中可以更方便迅速地解决问题。

这里列举几个调优的经验：

1） 分布式数据库数据是分布在多个节点的，当需要进行多表关联时，如果分区键设置不合理，关联查询嵌套较多，就无法避免数据在节点间流动，导致查询效率较低。针对这个问题，从以下几个方面进行优化：

a) 对所有的库表进行重新设计，合理设置分区键，分区键也是表的字段，表根据分区键字段将数据打散在各个节点，因此分区键设置时要从全局和交易局综合考虑，将交易中经常用来关联的字段设置为分区键，比如客户账户。

b) 对于更新评论较少且数据量不大的表，建议设置成全局表，即每个数据节点保存该表的全量数据，这样分片表和全局表进行关联时，也不会有节点间数据流动。

c) 对复杂 SQL 进行拆分，控制 SQL 嵌套层次，一条 SQL 控制只有两个表进行关联，嵌套不超过两层。拆分过程中可以考虑使用临时表（中间表），将中间数据放到临时表，中间表进行承上启下的关联。

d) 对交易业务逻辑进行重新设计，避免复杂 SQL 。

e) 数据库层面进行查询逻辑优化，支持某些复杂 SQL 。如：子查询上提、左连接消除、丰富下推逻辑以及基于统计信息的条件推导逻辑等，尽可能提高处理这种复杂 SQL 语句的性能。

作为核心系统，数据的一致性、准确性，系统运行的稳定性、机器发生故障时的高可用能力，甚至备份、恢复，都是十分关键的，这些内容更多是通过大量的测试进行验证，记录，整理成运维应急手册，以便问题发生时及时处理。

**【问题7】为了落地分布式数据库系统，应用、数据库层做了哪些改造？**

核心系统的原型版本，严格控制了SQL与代码的分离，SQL语句集中编写于Namesql层，且没有使用存储过程，逻辑由应用处理，这种设计结构，比较容易落地分布式数据库。

应用代码层，基本不需要修改，只有在SQL调整、数据库表设计调整仍没法解决的问题，才需要调整应用。这部分的内容很少，主要集中在批处理的部分。

首先要做的是兼容性改造，这里有两部分内容。一是数据库表的重建，二是SQL的函数、语法的调整。

数据库层，主要工作是表结构的调整。TDSQL提供三种模式的表：

1、 分片表 （能用分片表的就要使用分片表）

2、 广播表 （数据量少，如字典配置表）

3、 单片表 （尽量少使用，影响分布式数据的平均分布）

一般情况，都应选择分片表，广播表和单片表是为了解决特定问题才需要采用的。分片表的创建，同MYSQL相比较，多了一个分片键的设置。查询条件如果给分片键指定值，代理可以将SQL直接路由至具体的数据库节点，效率最优。如果未指定分片键值，查询效率也不受多少影响。对于多表关联查询，分片键的设置将十分关键，关联查询的分片键如果关联相等，那么表关联的关联数据都将落在同一个数据库节点，代理将SQL下发，各节点分别查询后，代理将数据汇总返回即可。如果没有分片键的关联，关联数据没有落在同一个数据库节点内，关联查询时需要将关联表的所有数据，拉取并缓存至代理，性能十分受影响。

分片键一个表只能选择一个，帐户、客户表一般选择客户号或是账号，但每个表有很多的字典字段，需要和字典表进行关联。为解决这个问题，新增了广播表这个类型，这种表，每个节点都保存有所有数据，也就解决了联表查询需要拉表的问题。

还有一种表是单节点表，这个表固定建在第一个分片数据库节点之上，支持所有MYSQL的语法和特性，在极端情况使用。

数据库层要做的工作就是给每个表进行分析，选择合适的表类型，分片表则要设置好合适的分片键。

SQL层，则是进行函数、语法的改造。可以使用程序批量替换，跑不通的再人为处理。

改造过程，表关联的查询方式，种类繁多，总会碰到无法支持的写法。先是尽可能的改成可能支持的写法，实在无法解决的，则要联系数据库厂商支持。对联表查询的结果也需要特别关注，有可能出现能跑，但数据错误的情况，也需要厂商及时修正。

下一步的工作至关重要，难度也最大。需要对每个交易、每个SQL进行性能优化处理。

性能优化必须以一定的表数据为基础，以性能测式为发现方法，通过管理台将慢查询语句提取出来，逐一进行优化。单表的优化同oracle等传统数据库，主要进行索引的设置。更多的优化集中于表关联，主要的改造有：

1、 索引调整

2、 SQL写法调整

3、 SQL拆分

4、 分表键调整

5、 表结构重构

6、 逻辑重构，应用调整

**【问题8】银行传统集中式数据库数据同步至分布式数据库的技术难点有哪些？贵行在实施 Sybase、Oracle到 TDSQL的数据同步时，遇到了哪些主要问题？**

数据同步，在技术层面没有难点。

稍微需要注意的主要有不同数据库对NULL和空的处理区别、字符集、特殊转义字符、分隔符、换行符。

不管是从Sybase到Oracle，还是Oracle到TDSQL，数据同步的方式都是一样的。以表为纬度，将源数据导出为文件，再通过工具将数据文件导入目标数据库。

数据的导出、导入，考虑性能问题，需要批处理化，进行一定的并发，具体的并发数与硬件配置相关，需要测试尝试来获取最优值。

数据迁移完成后，需要使用预先准备好的方法，进行数据核对。

**【问题9】分布式数据库不支持存储过程、触发器，如何迁移系统？**

存储过程，一般用于批处理、数据分析场景。

实时交易场景，考虑并发性能，需要避免使用存储过程。

以我行新的核心系统版本为例，实时交易的业务逻辑均通过应用实现，大量的数据库操作是简单的增删改查，外加少量的关联查询。这种应用设计能好很好的匹配目前的分布式数据库。

批处理也不再使用存储过程，一是转换为单笔交易并发处理，二是进行SQL拆分，将一个复杂关联语句分成多个简单或单表语句。

对存储过程的不支持，更多是分布式的原因，而非底层MYSQL版本问题，各分布式数据库基本都不支持。 即使支持，从实现原理分析，数据要有一个汇聚过程，性能也必定会大打折扣。过存储过程是应用数据库迁移至分布式数据库，必须解决的一个问题。

切换为分布式数据库，分布式带来的高并发、高可用、高性能、易扩展就是其价值。  对于系统层的运维也带来了改变， 可以不用再使用、维护小型机， 。oracle虽可运行于linux，但linux单机的稳定性较小机仍要差上许多，分布式才可弥补这个问题。

所以，切换为分布式数据库，和IT的整个架构规划相关，是否切换，切换为什么数据库，需要综合考虑。

备注：部分应用直接在SQL层、数据库层处理，初期改造十分快速容易，但容易

造成设计混乱问题。从这方面看，应用尽可能的从设计层进行优化，数据库只使用简单SQL，对于应用 后续 的性能优化、设计合理性、持续改造迭代，都十分有益。

**【问题10】分布式数据库复杂SQL的执行效率如何？**

直接以我行新核心的一些指标来说明：

高频交易：五千万账户数，4 台 X86 服务器，系统处理能力 6200TPS （笔每秒）。备注，我们根据我行的规模采用的 4 分片，所以压测的是 4 台服务器情况下的性能，后期通过在线扩容方式可以扩容到 8 分片、 16 分片、 32 分片、。。。，性能也会对应提升。

联机批量：200 并发下，每一万笔代发代扣 13 秒，系统负载在 10% 以下。例如我们生产环境的社保代发， 24 万笔耗时 5 分钟， 4 个数据库主节点 CPU 最高负载 10% ， IO 负载最高 8% 。

日终批量：我行新核心含信贷核算，以生产运行至今实际数据为例：年终结算日，核心日终步骤耗时20 分钟，年结步骤耗时 2 分钟；季度结息日，核心日终步骤 20 分钟，存款和贷款结息耗时 16 分钟。整个批量过程系统负责均在 10% 以下。备注，此处我行账户数不便对外透露，但是大家可以根据我行对外公布的总资产规模进行相应对照。

以上的这些性能指标实现，我行硬件（包含核心系统的应用服务器、数据库服务器、esb应用服务器、交换机）成本仅花了不到 700 万。

**【问题11】分布式数据库的数据备份恢复怎么做？**

TDSQL的 数据备份支持传统的备份方式。

系统每天一次全备，备份时并未做全局一致性备份，但支持任意时点的恢复，恢复 时 自动切平数据的，保证了 数据的 全局一致性恢复 ， RPO为0。

TD支持两地三中心的部署方式，保证了多活与高可用，单点故障 基本 不会影响系统运行。主节点出现问题时，RTO 为 1 5 分钟。

**【问题12】分布式核心使用的集中存储还是本机磁盘？**

分布式数据库使用Linux服务器，物理机，本机硬盘，不使用集中存储。

银行分布式数据库核心业务系统

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！