银行传统核心系统采用分布式数据库的选型讨论Word下载.docx

银行传统核心系统采用分布式数据库的选型讨论Word下载.docx

《银行传统核心系统采用分布式数据库的选型讨论Word下载.docx》由会员分享，可在线阅读，更多相关《银行传统核心系统采用分布式数据库的选型讨论Word下载.docx（9页珍藏版）》请在冰豆网上搜索。

因此，我行新核心系统在解决传统核心系统面临的问题的同时，需要实现传统银行业务向数字化方向转型需求，新核心系统建设的很重要的一个考虑点，需要具备支持海量数据场景下的高性能、高扩展、高可用等关键特征的数据库，从而引伸出银行核心数据库由集中式向分布式架构转型的需求。

我们通过多方了解，分析总结出分布式数据库能给我们带来的好处：

1）分布式数据库具备高性能、高可用、易扩展特点。

在高性能方面，分布式架构，可以同时利用多台服务器资源，达到超高并发、超高性能的效果。

在高可用方面，主备数据库强同步，可实现自动切换与恢复。

在易扩展方面，可以通过动态增加机器，来扩展容量与性能，避免影响业务。

2）在成本方面，使用X86服务器，摆脱国外商用数据库市场垄断，能够使软件及硬件成本下降，互联网最初选择分布式数据库原因在于成本优势。

3）使用国产分布式数据，软硬件不依赖国外厂商，可以“自主可控”。

4）数字化转型需求，与“小额大量”互联网业务融合，提升竞争力。

基于分布式的性能可扩展，将极大地提升并发性能的上限，可以满足未来几年互联网金融带来的交易量突发式增长，例如面对第三方接入后账户数的突增，可支持秒杀、红包、抢购、双“11”等海量在线客户导流，实现互联网金融业务融合。

3、选型和探索国产简介

（1）广泛交流，同业调研，进行POC测试

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

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

在对各个厂商的技术有了深度认识和学习后，我们选择了腾讯TDSQL和阿里OceanBase两款分布式数据库产品进行POC测试，进一步加深对分布式数据库的理解和掌握，基于POC测试结果，两者可谓“不分伯仲”，而且我们初步认为两种分布式数据库在我行中间业务等外围系统使用是完全没有问题的，而在交易种类多、场景复杂、重要程度极高的传统核心系统使用分布式数据库，当时还是没底的。

最终，考虑我行新核心系统建设周期较短，我们选择了基于“开源Mysql内核”的腾讯云TDSQL作为探索对象，因为相较于纯自研内核，采用成熟的开源Mysql内核，可以节省大量的测试内容和时间。

（2）外围系统先行试用

确定探索对象后，我们在中间业务系统和ECIF（企业客户信息系统）系统首先进行试用，积累了一定开发和运维经验。

例如，建表时分片字段的选择，复杂SQL的优化思路，与ORACLE索引的差异，将分布式数据库同步至集中式数据库的方案等，以及相关安装部署运维经验。

（3）内部赛马，最终决策

我行行做了一个大胆的决定：

同时开发两套新核心业务系统，一套基于国外某商用数据库，而另外一套则基于分布式数据库，然后进行“内部赛马”，然后分别对两个系统的稳定性、性能进行对比测试，根据测试结果再决定使用哪套。

经过整整一年的改造，无论是从性能成本，还是易用性，分布式数据库都表现出明显优势，进而最终新核心系统采用了分布式数据库，而之前采用集中式数据库的核心系统则保留为备用系统。

4、架构简介

我行的新核心系统物理架构如上图所示，分为三个层次：

核心通讯层、应用层、数据库集群层，三层间均采用F5设备进行负载均衡；

核心通讯层负责报文的统一转换和转发，由ESB和GXP组成，取消了tuxedo中间件通讯服务器，外围系统目前均通过ESB和GXP访问核心系统。

通讯层也是通过F5实现横向扩展和高可用。

应用层由新核心应用服务器组成，通过负载均衡实现横向扩展和高可用。

所以我们的通讯层和应用层尽量简化了部署和架构，同时具备横向扩展和高可用，也利于后期运维。

最下面是新核心的分布式数据库集群层，主要由接入网关和数据库组成。

接入网关主要负责业务的接入，sql解析和路由、分布式事务协调、数据的汇聚和分发等功能，网关节点不存储数据，节点间相互独立，通过硬件F5实现负载均衡。

中心机房和灾备机房各设置多台网关，确保中心机房和灾备机房均能接入业务。

数据库层为实际数据存储层，由mysql数据库集群组成，我行采用四个分片，每个分片采用一主三备的架构，其中中心机房一台主一台备，灾备机房两台备机，同步模式采用“同机房异步，异机房强同步”模式，确保主机房故障时灾备机房数据不丢失，实现机房级数据强一致容灾。

另外，如图中蓝色所示，通过同步工具可以实现分布式的数据库与集中式数据库数据准实时同步。

备注：

负责分布式数据库集群管理的组件未在图中体现，我行采用的分布式数据库管理组件由分布式注册中心、切换调度、运营管理平台等管理组件组成，主要负责全局信息的收集和统一发布，各分布式组件间的协调，主备切换，自动化运维等。

5、探索过程中的技术难点

（1）应用与分布式数据库的适配难题

应用和分布式数据库的适配性改造是难度最大以及最需要资源投入的部分，既需要应用的适配改造，甚至数据库层面也需要做一定的改造，我行采用的方式是找专业的团队做专业的事，找应用的厂商做应用，找数据库的厂商做数据库，最关键的是由行方、应用厂商、数据库厂商组成技术攻坚小组，专门解决各类改造过程中的问题，也能达到培养行方开发和运维人员的目的。

我行新核心系统的整个改造实施过程分为两个阶段，第一个阶段是产品适配和功能性改造，第二个阶段是性能优化。

整个改造过程是从简单到复杂，我们是先从高频交易入手，集中处理与高频交易相关的业务以及子系统，然后是跑批类交易，跑批与高频交易相比，SQL相对复杂冗余但是占总交易类的比重较低。

解决了高频交易其实就已经解决了大部分匹配问题，我行在这个过程中积累了丰富的调优经验，这些经验再应用到其它业务系统中可以更方便迅速地解决问题。

总的原则就是尽可能让SQL语句限制在同一个数据节点内，减少跨节点数据关联查询。

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

1）分布式数据库数据是分布在多个节点的，当需要进行多表关联时，如果分区键设置不合理，关联查询嵌套较多，就无法避免数据在节点间流动，导致查询效率较低。

针对这个问题，从以下几个方面进行优化：

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

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

c）对复杂SQL进行拆分，控制SQL嵌套层次，一条SQL控制只有两个表进行关联，嵌套不超过两层。

拆分过程中可以考虑使用临时表（中间表），将中间数据放到临时表，中间表进行承上启下的关联。

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

e）数据库层面进行查询逻辑优化，支持复杂某些复杂SQL。

如：

子查询上提、左连接消除、丰富下推逻辑以及基于统计信息的条件推导逻辑等，尽可能提高处理这种复杂SQL语句的性能。

（2）数据一致性考虑

分布式数据库的数据一致性要从两个方面考虑，一个是主备节点之间的一致性，另外是分布式事务的一致性，即多个数据节点间数据的一致性。

1）主备节点间我们采用强同步模式，保证主备间数据都落盘（日志落盘）才会应答成功，主备间的一致性需要注意，首先主备间通常是通过日志进行同步的，所以尽量要减少大事务，否则会导致备机延时过大，同时也可能阻塞其他事务；

其次，主备间同步的效率需要关注，由于主备间采用强同步，不同数据库厂商在解决此问题时解决方案不同，选型时建议进行对比测试，看强同步和；

最后，主备间一致性建议在测试阶段进行全字段的一致性校验，确保主备切换不丢数据，例如基于MYSQL的分布式数据库可以使用pt-table-checksum工具进行主备一致校验，而纯自研的数据库，主备的全字段一致性校验也是有必要的。

2）分布式事务的一致性：

分布式事务（交易）一致性是银行核心业务系统的基本要求，核心业务系统交易一致性要求远高于电商平台和其他互联网应用，交易一致性指的是数据库事务管理必须满足ACID要求，否则将会发生交易一致性问题。

由于分布式架构采取分库分表策略，导致跨库跨表的事务增多，如果采用传统交易中间件层二阶段提交（TwoPhaseCommit）机制来进行事务管理，则会引起性能和可用性问题，成为了影响分布式架构在银行核心业务应用的最大障碍。

针对此问题，我们通过以下几个方面去应对：

a）外请专家团队，一起对分布式事务的实现机制进行充分理论论证，尤其是异常场景，例如我们采用的分布式数据库是基于mysql原生的XA外部事务，通过两阶段提交的方式，实现分布式事务的一致性。

当然通过专家的分析讨论，认为分布式事务一致性能保证。

b）破坏性测试验证：

制定分布式事务测试方案，通过程序并发发起分布式事务，同时对数据库主节点进行频繁的重启，我们通过24小时内1000次的主节点故障，未发现分布式事务不一致和主备不一致的情况。

此类测试始终贯穿整个验证测试过程。

c）业务验证测试：

在SIT和UAT业务测试中进行验证。

若在这多次的验证中有一次不一致，那分布式数据库可能我们就不会采用，但正是经历了大量的破坏性测试、业务测试和理论验证，我们才能放心使用在核心系统中。

（3）平台整体性故障

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

我们对这个兜底方案进行了大量的业务验证，真正能够做到切换后业务正常开展，而不是仅仅是数据层面的同步，有了兜底方案，也为决策难题提供了重要支持。

这里介绍下我们采用的同步方案供大家讨论和互相交流：

这个同步工具跟Oracle的OGG有点类似，通过将分布式数据库（此处为TDSQL）的日志文件进行解析，然后上传到kafka队列，最后由消费者进程从队列取到消息应用到集中式数据库，我们新核心未使用触发器、存储过程等其他数据库对象，所以只要进行表同步，同步复杂度低，相对稳定度较高。

分布式到集中式的数据同步，同步延迟为秒级，同步效率可以达到15000QPS（2018年6月份版本）。

若切换数据源，必须全量数据校验，确保分布式与集中式两个数据源的数据一致。

如需要切换数据库时，也比较简单，主要分为停应用程序，等两套数据源同步完成，两套数据库全量数据校验，调整相关参数，启动应用程序，业务验证和恢复，整个过程30分钟以内，其中耗时最长的是两套数据库全量数据校验，如果在极端情况下也可以跳过此步骤，例如主用数据库已经不可访问，可以先对外恢复业务，因为交易日志和数据库日志都在，所以不会造成数据丢失，后期通过数据校对的方式进行相关修正。

（4）运营过程中问题

考虑到分布式数据库和集中式数据库的差异，系统上线后的开发运维的模式会有新的变化，其中最关键的因素是开发运维人才梯队的培养，我行采用的是技术攻坚小组的模式，由应用厂商、数据库厂商以及我们自己行方人员组成，行方人员由开发和运维人员互相融合，三方人员各自发挥各自的专业优势，专业的团队做专业的事，在长达近一年的整个攻坚的过程中，处理各类疑难杂症，培养了我们自己的开发运维队伍，并且形成了相关开发和运维手册，期间所有分布式数据库的安装部署、调优、问题排查，基本都是我行技术人员进行主导操作，系统上线后的系统开发和运维的自主掌握程度非常高，尤其是运维团队，数据库的基本问题和复杂问题都能自主运维，自主运维基本100%，开发截止目前，自主开发也达到80%以上。

最后，运维过程中需要数据库厂商提供自动化运维工具，我行采用的腾讯TDSQL分布式数据库，

6、我行分布式数据库核心性能指标分享

最后跟大家分享一下我行新核心的一些指标：

高频交易：

五千万账户数，4台X86服务器，系统处理能力6200TPS（笔每秒）。

备注，我们根据我行的规模采用的4分片，所以压测的是4台服务器情况下的性能，后期通过在线扩容方式可以扩容到8分片、16分片、32分片、。

。

，性能也会对应提升。

联机批量：

200并发下，每一万笔代发代扣13秒，系统负载在10%以下。

例如我们生产环境的社保代发，24万笔耗时5分钟，4个数据库主节点CPU最高负载10%，IO负载最高8%。

日终批量：

我行新核心含信贷核算，以生产运行至今实际数据为例：

年终结算日，核心日终步骤耗时20分钟，年结步骤耗时2分钟；

季度结息日，核心日终步骤20分钟，存款和贷款结息耗时16分钟。

整个批量过程系统负责均在10%以下。

备注，此处我行账户数不便对外透露，但是大家可以根据我行对外公布的总资产规模进行相应对照。

以上的这些性能指标实现，我行硬件成本仅花了不到700万。

-全文完-