银行核心系统采用分布式数据库的最佳实践

1、 银行核心系统采用分布式数据库的探索 | 最佳实践 【摘要】本文介绍了农商行在新核心系统采用分布式数据库的探索，包括需求分析、选型、架构设计，重点介绍了在此过程中遇到的难点和调优的经验，是值得参考的一手实践分享。【作者】卢丽欢，张家港农商行数据库团队负责人，擅长分布式数据库(TDSQL，GaussDB 200等)和集中式数据库(oracle，mysql等)的排障和调优，全程负责张家港农商行新核心分布式数据库的选型、测试、论证以及落地，积累了丰富的银行核心业务系统分布式数据库落地经验。1、 背景张家港农商行探索实践分布式数据库正好是在核心系统需要升级改造的大背景下，我行老核心采用的是 Sybas

2、e 数据库，最开始的版本是 Sybase12.5 ，中间不断地进行版本升级与优化，把 Sybase数据库的性能发挥到了极致，而 Sybase数据库目前已经不是主流了，性能已经无法满足我行业务发展需求，而且问题定位这一块主要靠经验，看日志等，监控展示手段有限，所以此次新核心系统升级，必须将Sybase 数据库进行更换，面临着数据库的选型，因为无论将 Sybase升级到像 Oracle 这种传统集中式数据库还是分布式数据库，都是巨大的变化，都要面临巨大的挑战和风险。而分布式数据库能提供大并发弹性扩展功能，且已经在银行互联网核心应用成熟，目前多个银行都在探索并已经在互联网核心落地，可以看出这是未来的

3、一个趋势所在。2 、需求随着近年来互联网、云计算、大数据、人工智能等技术的飞速发展，银行业务量、数据量也呈现爆发式增长趋势，银行业务发展与传统关系型数据库已经呈现出非常多的矛盾。这主要表现为，数据量爆发式增长与传统数据库有限容量之间的矛盾；业务处理的高并发系统压力与传统数据库性能无法水平扩展之间的矛盾；越来越高标准的业务连续性要求与昂贵的传统数据库容灾技术越来越难以满足要求之间的矛盾。因此，我行新核心系统在解决传统核心系统面临的问题的同时，需要实现传统银行业务向数字化方向转型需求，新核心系统建设的很重要的一个考虑点，需要具备支持海量数据场景下的高性能、高扩展、高可用等关键特征的数据库，从而引申

4、出银行核心数据库由集中式向分布式架构转型的需求。我们通过多方了解，分析总结出分布式数据库能给我们带来的好处：1 ）分布式数据库具备高性能、高可用、易扩展特点。在高性能方面，分布式架构，可以同时利用多台服务器资源，达到超高并发、超高性能的效果。在高可用方面，主备数据库强同步，可实现自动切换与恢复。在易扩展方面，可以通过动态增加机器，来扩展容量与性能，避免影响业务。2 ）在成本方面，使用 X86 服务器，摆脱国外商用数据库市场垄断，能够使软件及硬件成本下降，互联网最初选择分布式数据库原因在于成本优势。3 ）使用国产分布式数据，软硬件不依赖国外厂商，可以“自主可控”。4 ）数字化转型需求，与“小额大

5、量”互联网业务融合，提升竞争力。基于分布式的性能可扩展，将极大地提升并发性能的上限，可以满足未来几年互联网金融带来的交易量突发式增长，例如面对第三方接入后账户数的突增，可支持秒杀、红包、抢购、双“ 11 ”等海量在线客户导流，实现互联网金融业务融合。3 、选型和探索（ 1 ）广泛交流，同业调研，进行 POC 测试当时国内的关系型分布式数据库产品非常多，可选择的也很多，我们首先对国内分布式数据库主流厂商数据库产品进行了多轮次深入的技术交流，例如腾讯 TDSQL 、 OceanBase 、华为 GaussDB 、热璞 HotDB 以及京东云数据库等国内主流适合做实时交易的 OLTP 型数据库。此外

6、，我们对微众银行核心和南京银行互联网核心建设进行了现场调研，学习建设经验和遇到的问题。在对各个厂商的技术有了深度认识和学习后，我们选择了腾讯 TDSQL 和另一款分布式数据库产品进行 POC 测试，进一步加深对分布式数据库的理解和掌握，基于 POC 测试结果，两者可谓“不分伯仲”，而且我们初步认为两种分布式数据库在我行中间业务等外围系统使用是完全没有问题的，而在交易种类多、场景复杂、重要程度极高的传统核心系统使用分布式数据库，当时还是没底的。最终，考虑我行新核心系统建设周期较短，我们选择了基于“开源 MySQL 内核”的腾讯云 TDSQL 作为探索对象，因为相较于纯自研内核，采用成熟的开源 M

7、ySQL内核，可以节省大量的测试内容和时间。（2） 外围系统先行试用确定探索对象后，我们在中间业务系统和 ECIF （ 企业客户信息系统 ）系统首先进行试用，积累了一定开发和运维经验。例如，建表时分片字段的选择，复杂 SQL 的优化思路，与 Oracle索引的差异，将分布式数据库同步至集中式数据库的方案等，以及相关安装部署运维经验。（ 3 ）内部赛马，最终决策我行做了一个大胆的决定：同时开发两套新核心业务系统，一套基于国外某商用数据库，而另外一套则基于分布式数据库，然后进行“内部赛马”，然后分别对两个系统的稳定性、性能进行对比测试，根据测试结果再决定使用哪套。经过整整一年的改造，无论是从性能成

8、本，还是易用性，分布式数据库都表现出明显优势，进而最终新核心系统采用了分布式数据库，而之前采用集中式数据库的核心系统则保留为备用系统。4 、架构简介我行的新核心系统物理架构如上图所示，分为三个层次：核心通讯层、应用层、数据库集群层，三层间均采用 F5 设备进行负载均衡。核心通讯层负责报文的统一转换和转发，由 ESB 和 GXP 组成，取消了 tuxedo 中间件通讯服务器，外围系统目前均通过 ESB 和 GXP 访问核心系统。通讯层也是通过 F5 实现横向扩展和高可用。应用层由新核心应用服务器组成，通过负载均衡实现横向扩展和高可用。所以我们的通讯层和应用层尽量简化了部署和架构，同时具备横向扩展

9、和高可用，也利于后期运维。最下面是新核心的分布式数据库集群层，主要由接入网关和数据库组成。接入网关主要负责业务的接入，sql 解析和路由、分布式事务协调、数据的汇聚和分发等功能，网关节点不存储数据，节点间相互独立，通过硬件 F5 实现负载均衡。中心机房和灾备机房各设置多台网关，确保中心机房和灾备机房均能接入业务。数据库层为实际数据存储层，由MySQL数据库集群组成，我行采用四个分片，每个分片采用一主三备的架构，其中中心机房一台主一台备，灾备机房两台备机，同步模式采用“同机房异步，异机房强同步”模式，确保主机房故障时灾备机房数据不丢失，实现机房级数据强一致容灾。另外，如图中蓝色所示，通过同步工具

10、可以实现分布式的数据库与集中式数据库数据准实时同步。备注：负责分布式数据库集群管理的组件未在图中体现，我行采用的分布式数据库管理组件由分布式注册中心、切换调度、运营管理平台等管理组件组成，主要负责全局信息的收集和统一发布，各分布式组件间的协调，主备切换，自动化运维等。5 、探索过程中的技术难点（1） 应用与分布式数据库的适配难题应用和分布式数据库的适配性改造是难度最大以及最需要资源投入的部分，既需要应用的适配改造，甚至数据库层面也需要做一定的改造，我行采用的方式是找专业的团队做专业的事，找应用的厂商做应用，找数据库的厂商做数据库，最关键的是由行方、应用厂商、数据库厂商组成技术攻坚小组，专门解决

11、各类改造过程中的问题，也能达到培养行方开发和运维人员的目的。我行新核心系统的整个改造实施过程分为两个阶段，第一个阶段是产品适配和功能性改造，第二个阶段是性能优化。整个改造过程是从简单到复杂，我们是先从高频交易入手，集中处理与高频交易相关的业务以及子系统，然后是跑批类交易，跑批与高频交易相比， SQL 相对复杂冗余但是占总交易类的比重较低。解决了高频交易其实就已经解决了大部分匹配问题，我行在这个过程中积累了丰富的调优经验，这些经验再应用到其它业务系统中可以更方便迅速地解决问题。总的原则就是尽可能让 SQL 语句限制在同一个数据节点内，减少跨节点数据关联查询。这里列举几个调优的经验：1） 分布式数

12、据库数据是分布在多个节点的，当需要进行多表关联时，如果分区键设置不合理，关联查询嵌套较多，就无法避免数据在节点间流动，导致查询效率较低。针对这个问题，从以下几个方面进行优化：a) 对所有的库表进行重新设计，合理设置分区键，分区键也是表的字段，表根据分区键字段将数据打散在各个节点，因此分区键设置时要从全局和交易局综合考虑，将交易中经常用来关联的字段设置为分区键，比如客户账户。b) 对于更新评论较少且数据量不大的表，建议设置成全局表，即每个数据节点保存该表的全量数据，这样分片表和全局表进行关联时，也不会有节点间数据流动。c) 对复杂 SQL 进行拆分，控制 SQL 嵌套层次，一条 SQL 控制只有

13、两个表进行关联，嵌套不超过两层。拆分过程中可以考虑使用临时表（中间表），将中间数据放到临时表，中间表进行承上启下的关联。d) 对交易业务逻辑进行重新设计，避免复杂 SQL 。e) 数据库层面进行查询逻辑优化，支持复杂某些复杂 SQL 。如：子查询上提、左连接消除、丰富下推逻辑以及基于统计信息的条件推导逻辑等，尽可能提高处理这种复杂 SQL 语句的性能。（2） 数据一致性考虑分布式数据库的数据一致性要从两个方面考虑，一个是主备节点之间的一致性，另外是分布式事务的一致性，即多个数据节点间数据的一致性。1 ）主备节点间我们采用强同步模式，保证主备间数据都落盘（日志落盘）才会应答成功，主备间的一致性需

14、要注意，首先主备间通常是通过日志进行同步的，所以尽量要减少大事务，否则会导致备机延时过大，同时也可能阻塞其他事务；其次，主备间同步的效率需要关注，由于主备间采用强同步，不同数据库厂商在解决此问题时解决方案不同，选型时建议进行对比测试，看强同步和；最后，主备间一致性建议在测试阶段进行全字段的一致性校验，确保主备切换不丢数据，例如基于 MYSQL 的分布式数据库可以使用 pt-table-checksum 工具进行主备一致校验，而纯自研的数据库，主备的全字段一致性校验也是有必要的。2 ）分布式事务的一致性：分布式事务（交易）一致性是银行核心业务系统的基本要求，核心业务系统交易一致性要求远高于电商平

15、台和其他互联网应用，交易一致性指的是数据库事务管理必须满足 ACID 要求，否则将会发生交易一致性问题。由于分布式架构采取分库分表策略，导致跨库跨表的事务增多，如果采用传统交易中间件层二阶段提交（ Two Phase Commit ）机制来进行事务管理，则会引起性能和可用性问题，成为了影响分布式架构在银行核心业务应用的最大障碍。针对此问题，我们通过以下几个方面去应对：a) 外请专家团队，一起对分布式事务的实现机制进行充分理论论证，尤其是异常场景，例如我们采用的分布式数据库是基于 mysql 原生的 XA 外部事务，通过两阶段提交的方式，实现分布式事务的一致性。当然通过专家的分析讨论，认为分布式

16、事务一致性能保证。b) 破坏性测试验证：制定分布式事务测试方案，通过程序并发发起分布式事务，同时对数据库主节点进行频繁的重启，我们通过 24 小时内 1000 次的主节点故障，未发现分布式事务不一致和主备不一致的情况。此类测试始终贯穿整个验证测试过程。c) 业务验证测试：在 SIT 和 UAT 业务测试中进行验证。若在这多次的验证中有一次不一致，那分布式数据库可能我们就不会采用，但正是经历了大量的破坏性测试、业务测试和理论验证，我们才能放心使用在核心系统中。（3） 平台整体性故障当时我们探索分布式数据库的时候，国内没有分布式数据库在银行传统核心领域应用的成功案例，而银行核心系统是银行最重要的系

17、统，一旦出现问题，会造成严重的社会问题，因此必须做好极端情况的应急响应，我们采取的方案是分布式数据库和集中式数据库数据准实时同步的，应用层面同时支持两套数据库，主用是分布式数据库，数据会准实时同步到集中式数据库，当分布式数据库完全不可用的情况下，通过修改配置相关文件和数据库内容，快速切换至集中式数据库，并对外恢复业务，通过我们上线演练实测，这个切换的过程在 30 分钟以内，期间大部分时间花费在两套数据库的数据一致校验方面，数据的校验我们从表的记录数和账务核对两个方面进行，并且平时每天在业务低峰期进行校验，验证分布式和集中式数据库的数据一致性。我们对这个兜底方案进行了大量的业务验证，真正能够做到

18、切换后业务正常开展，而不是仅仅是数据层面的同步，有了兜底方案，也为决策难题提供了重要支持。这里介绍下我们采用的同步方案供大家讨论和互相交流：这个同步工具跟 Oracle 的 OGG 有点类似，通过将分布式数据库（此处为 TDSQL ）的日志文件进行解析，然后上传到 kafka 队列，最后由消费者进程从队列取到消息应用到集中式数据库，我们新核心未使用触发器、存储过程等其他数据库对象，所以只要进行表同步，同步复杂度低，相对稳定度较高。分布式到集中式的数据同步，同步延迟为秒级，同步效率可以达到 15000QPS （ 2018 年 6 月份版本）。若切换数据源，必须全量数据校验，确保分布式与集中式两个

19、数据源的数据一致。如需要切换数据库时，也比较简单，主要分为停应用程序，等两套数据源同步完成，两套数据库全量数据校验，调整相关参数，启动应用程序，业务验证和恢复，整个过程 30 分钟以内，其中耗时最长的是两套数据库全量数据校验，如果在极端情况下也可以跳过此步骤，例如主用数据库已经不可访问，可以先对外恢复业务，因为交易日志和数据库日志都在，所以不会造成数据丢失，后期通过数据校对的方式进行相关修正。（4） 运营过程中问题考虑到分布式数据库和集中式数据库的差异，系统上线后的开发运维的模式会有新的变化，其中最关键的因素是开发运维人才梯队的培养，我行采用的是技术攻坚小组的模式，由应用厂商、数据库厂商以及我

20、们自己行方人员组成，行方人员由开发和运维人员互相融合，三方人员各自发挥各自的专业优势，专业的团队做专业的事，在长达近一年的整个攻坚的过程中，处理各类疑难杂症，培养了我们自己的开发运维队伍，并且形成了相关开发和运维手册，期间所有分布式数据库的安装部署、调优、问题排查，基本都是我行技术人员进行主导操作，系统上线后的系统开发和运维的自主掌握程度非常高，尤其是运维团队，数据库的基本问题和复杂问题都能自主运维，自主运维基本 100% ，开发截止目前，自主开发也达到 80% 以上。最后，运维过程中需要数据库厂商提供自动化运维工具。6、 我行分布式数据库核心性能指标分享最后跟大家分享一下我行新核心的一些指标：高频交易：五千万账户数， 4 台 X86 服务器，