数据库 频道

NewSQL 分布式数据库在银行场景的实践

摘要】在金融领域,绝大多数的银行业应用设计都是基于传统单机关系型数据库,没有从整体应用架构考虑与第三代分布式数据库进行适配,尤其在银行核心系统应用第三代分布式数据库案例甚少,没有可复制的成功经验可以借鉴,面临的挑战主要有两个方面,分别是数据库自身的机制问题和核心系统应用的复杂度和差异性挑战……

【作者】luxh08,任职某互联网银行科技运维部,负责银行内IT科技部生产运行及管理方面的工作,擅长银行基础设施的建设和运维管理,以及分布式数据库的架构设计与实践。


一、项目背景

随着新一代信息技术在金融领域的蓬勃发展,科技与金融业务不断融合,为金融行业注入新的发展活力,使科技成为金融高质量发展的“新引擎”。数据库作为IT基础设施最关键的组件之一,广泛应用于银行业务系统,目前在我国IT基础设施领域银行业金融机构多数依赖于国外数据库产品,未能真正实现技术安全可控。其中,银行核心系统作为对事务强一致性、高安全性、高稳定性要求最高的金融联机交易场景,其国产化进程将成为IT基础设施自主国产化的最后一公里,也将是国产数据库产品成熟度最有力的证明。

某某银行成立之初,选择Mariadb技术路线,选型考量是产品的开源性和公立性,作为一家银行,数据安全也就是客户资金的安全,Mariadb Galera Cluster强同步机制是考虑的关键点,我们在系统建设阶段制定了严格的数据技术标准和配置规范、统一使用Mysql协议,禁用存储过程,规范SQL语法,限制事务大小等措施进行数据库的标准统一,但是随着业务规模的发展,Mariadb数据库带来了复杂性、性能和容量方面的挑战。为了解决这个难点,我们开始在一些支付系统上尝试采用分库分表数据库架构,来解决业务量增长带来的数据库性能和容量问题,但是解决了老问题又来了新的问题,多实例分库架构带来了应用侵入和全局一致性等问题,这些问题只能从应用层面通过代码去解决,这样就增加了研发成本。同时给运维工作也带来了复杂度,首先分库分表架构的扩容是一个庞大的工作量,再者DDL变更操作也需要在业务量较小的时间段来执行,为了面对以上问题,我们开始考虑有没有一种新的数据库架构能解决以上所有问题。


二、数据库架构选型分析

数据库从其主要实现方式、技术架构和优势特点等方面可以分为以下三代:

1.第一代传统单机关系数据库

传统单机关系型数据库架构主要通过主备机方式实现数据的高可用性,以Oracle 、DB2等国外知名产品为主要代表,是目前国内大部分银行业关键交易场景的支撑技术。传统单机关系型数据库无法做到线性的性能扩容,其扩展方式只能采用垂直资源增加方式,无法横向扩展,其稳定性依赖于成本昂贵的的硬件设备,不能支撑快速增长的金融业务需求。

2.第二代中间件关系数据库

第二代中间件关系数据库采用单机数据库引擎与中间件代理层相结合的设计方式,实现了良好的水平扩展性,以第二代开源MySQL分库分表架构为主要代表,主要应用于技术领先的互联网银行、直销银行的关键交易场景。

目前,从互联网领域发展而来的第二代中间件关系数据库技术在行业应用中成熟度较高,其实现方式通常为开源的单机数据库(例如MySQL或者PostgreSQL)与分布式数据库中间件相结合的方式,或者基于开源数据库的深度定制。此类数据库虽为分布式架构,但存在有以下问题:一是对金融复杂交易类业务场景的支撑力不足。第二代中间件关系数据库产生于传统互联网业务场景,无法满足银行业高安全等级的核心交易场景,其自身的高可用、容错及同城/异地容灾等方面的能力不足;二是对业务代码和数据建模的侵入性较大。第二代中间件关系数据库在数据库建模设计时,每张表都需要显示指定分片键,对业务侵入性极大,容易造成业务代码改造难度大、成本高、工作量繁重、后期运维困难等问题,无法高效处理复杂的交易逻辑和金融级事务交易。

3.第三代 NewSQL 关系数据库

NewSQL关系数据库采用内核级自动分片策略,结合高效分布式事务模型,是关系型数据库和NoSQL数据库的完美组合。既可以实现水平线性扩展,又避免使用分片键,既保证了应用程序的使用透明,又极大降低了业务迁移中的工作量,是目前业界最先进的全分布解决方案,主流产品都是基于GoogleSpanner论文衍生的产品。

综合数据库技术的三代发展历程,我们考虑采用第三代NewSQL分布式数据库架构解决存在问题,在18年初开始测试了当时主流NewSQL架构,我们选择支持Mysql协议的NewSQL架构,有以下几个方面考虑:

(1)完全兼容mysql协议,满足我们数据库规范,应用适配成本较小;

(2)分布式架构无应用侵入,解放了开发人员繁重的代码改造工作;

(3)扩容工作将变的非常简单,轻松的增加服务器带来线性的性能提升,最重要的是支持ddl类在线变更,其实DBA大部分工作其实都是数据变更和提取,我们正在建设数据库自动化平台,计划和devops对接实现数据库自动化变更。

(4)安全性和可用性考虑,本身采用raft的多数派协议,将节点部署不同地点就可以实现同城或者异地多活架构,还可以和mysql数据库架构进行实时数据复制。


三、银行应用场景分析及难点

某某银行从18年就开始尝试NewSQL数据库架构,生产环境19年初最早在线查询场景进行了使用,技术储备一定阶段之后上线了批处理业务场景,到19年10月上线了第一个真正的关键联机场景,互联网贷款系统,互联网贷款系统目前每天1400W日交易量,QPS日峰值9W次,总数据量达到8T以上。我们在联机场景已经上线了贷款业务场景、支付业务场景、核心系统目前也完成了应用适配,已经在生产环境并行上线试运行。

银行核心系统是银行场景中ACID特性要求最高的,也是典型的联机交易场景,在银行场景中对数据库成熟度要依赖性最强的应用系统,后续NewSQL在银行业务场景应用介绍,按照银行核心场景应用项目进行展开。与前两代数据库相比,NewSQL分布式数据库是关系型数据库和非关系型数据库的结合体,在架构和机制上都有很大的差别。在金融领域,绝大多数的银行业应用设计都是基于传统单机关系型数据库,没有从整体应用架构考虑与第三代分布式数据库进行适配,尤其在银行核心系统应用第三代分布式数据库案例甚少,没有可复制的成功经验可以借鉴,面临的挑战主要有两个方面,分别是数据库自身的机制问题和核心系统应用的复杂度和差异性挑战。

在数据库自身的机制方面,NewSQL分布式数据库在银行应用场景应用主要有以下几个问题:

1、乐观锁适配问题。乐观锁在事前对表不会加锁,只在提交的时候比对提交版本号,不能保证每笔交易都能提交成功,在高并发的金融记账业务场景里,会造成大量的交易超时,出现用户短款现象,不能满足银行业务连续性和数据“强一致性”的要求。

2、隔离级别问题。在NewSQL分布式数据库应用过程中,由于原有银行核心系统的整体设计一般采用RC隔离级别,嵌套事务无法在RR隔离级别运行,需要对核心系统进行RR隔离级别的适配改造。

3、串行机制问题。与传统单机关系型数据库相比,分布式数据库为保证所有节点的事务一致性,采用二阶段提交机制,其处理单个SQL语句的执行效率较低,导致其整体性能反而没有传统单机关系型好,因此在分布式数据库应用设计时应尽量考虑并行机制,避免串行机制。

在银行核心系统应用方面,NewSQL分布式数据库应用主要有以下几个问题:

1、核心系统应用的复杂度。银行核心系统的业务逻辑复杂,与其相关联的系统众多,数据库又是其底层基础,进行NewSQL分布式数据库适配将会对核心系统应用有很大的改动,也对应用适配提出了更高的要求。

2、业务测试的差异性。在业务功能测试过程中,业务测试人员通常按照测试样例进行人工验证,并不能完全模拟生产环境下的业务交易,产品功能缺陷和代码BUG的风险仍然存在。


四、分布式数据库在核心场景实践

为了解决以上难点,某某银行深入研究NewSQL分布式数据库在银行业核心系统的建设应用,妥善解决NewSQL分布式数据库产品在数据一致性、业务场景优化、数据迁移保障、并行上线验证等一系列的问题,我们主要完成了以下几个方面工作。

第一是数据库适配性改造问题,主要是一些语法和功能性转换,包括格式转换,函数转换,伪列替换,还有就是采用java代码重构触发器功能。

第二是事务锁机制问题,当时分布式数据库版本只有乐观锁版本,在热点账户场景遇到了严重的问题,首先大概说下什么是热点账户场景,在业务层面说就是大量的动账类请求同一个账户余额,并且要实时更新余额,不能存在透支情况。在技术层面来说,就是同一行数据有大量的操作,并且读操作也是select for update独占,这样会引起大量的行级争抢,是一个典型的强ACID场景。在热点账户场景,采用乐观锁机制,成功率最高只有80%,tps只有个位数,所以说乐观锁机制不适合这样强ACID操作,因-为乐观锁是通过版本号控制事务提交的,业务就会出现大量的短款交易,远远达不到核心业务的要求,决定改造数据库以支持悲观锁版本。

第三是数据迁移问题,我们测试了三种方式,分别是kettle全量+kettle增量,优势是对应用侵入小,直接可以使用,缺点是增量需要停业务。第二种和第三种方式都使用了ogg技术,ogg需要数据库表有主键和唯一索引,对业务是有侵入性的,经过评估,为了保证现有生产环境稳定性,决定放弃ogg技术,我们采用kettle方式进行数据迁移,但是需要牺牲一定的停机时间。

第四是性能测试阶段,测试的交易场景主要有动账类和开户类操作。主要遇到了以下几个方面问题。

(1)读热点数据问题,大表读热点,在建表阶段通过手工方式通过热点打散机制将表数据平准分配到各数据节点。小表热点,只能通过cache解决,所以我们通过应用层改造到到redis中解决。

(2)交易链路长问题,分布式数据库单个sql性能和单机关系型数据库有差距的,由于二阶段和多节点网络延时造成的,通过应用改造,将交易拆分不同小的原子并发处理。

(3)事务隔离性问题,采用的分布式数据库是si隔离级别,通过版本号控制提交一致性,在嵌套类事务,版本号冲突造成提交不成功,我们进行代码改造消除掉嵌套事务解决。

(4)核心批量类交易,分布式数据库性能和原先的单机库库差不多,我们通过分析大部分时间都在逻辑运算,我们通过增加分布式数据库计算节点,可以线性的减少核心批量的执行时间。

第五也是最难解决的问题,就是解决热点账户场景性能问题,主要有热点账户转账交易、非热点账户转账交易、查询交易。

在热点账户场景,这时候分布式数据库已经换成悲观锁版本,成功率已经可以达到100%,但是单次sql执行效率低,热点账户由于存在单行的争抢,增加并发机制也提升不了tps,需要做应用改造解决。非热点账户和查询场景,没有行争取,应用通过增加并发机制,可以线性的提升tps。

下面重点介绍下,针对银行核心系统热点账户场景的解决方案,热点账户其实在单机关系型数据库也有一些问题,在并发数高的时间,也存在一些超时,在数据库层面也很难解决,我们是通过应用改造解决的。首先我们对sql语句进行了优化,减少事务持锁时间,有一些效果,但是不能解决根本问题。接下来我们解耦贷款记账场景,将贷款业务实时记账接口改成批量记账,通过日终汇总记账规避掉热点账户场景。

贷款场景业务解耦示意图:

但是支付和存款等其他业务场景热点账户问题目前还没有解决,我们通过应用将账户余额改造成多个子余额,在核心系统数据结构设计中,一个账户余额对应表结构的一行数据,我们通过子余额将账户余额改造成到表结构多个行,来分散行级争抢,通过4、8、16、32子余额扩展,可以实现线性的性能提升,在16子余额场景中,性能可以达到300tps,性能比目前生产库还提升了5倍左右,完美的解决了热点账户问题。

账户子余额方案示意图 :

五、效果总结

在银行多活核心系统上应用NewSQL分布式数据库,突破了原有数十年银行业核心系统数据库的IT建设模式,提升了银行业信息技术安全应用水平,推动了金融与科技的深度融合,打破了金融行业对国外数据库关键基础软件产品的依赖。同时,针对分布式数据库的特性,对应用架构、业务逻辑、测试方法进行了优化和创新,实现了核心系统用户信息、账户信息、交易信息等关键数据的统一数据管理,节省60%的硬件采购成本,缩减85%批量处理时间,提升每秒实时数据处理超过90000/QPS,其主要创新点如下:

1、设计热点账户子余额改进方案,成功解决银行核心系统热点账户场景的性能问题,提供了一种切实可靠的解决思路;

2、改造贷款系统记账业务逻辑,有效解决潮汐海量用户级互联网贷款业务场景对银行核心系统带来的性能挑战;

3、利用NewSQL分布式数据库的性能横向可扩展,实现银行核心系统性能的动态快速扩展;

4、满足数据中心多活的数据库架构模式,利用多副本技术,达到服务器级、机柜级、中心级容灾要求,为银行核心系统提供更好的高可用性。

在金融科技蓬勃发展的背景下,新一代分布式数据库将在金融行业迅速发展,未来仍将是整个金融行业应重点关注的话题。展望未来,本课题还将会积极探索分布式数据库的技术应用,进一步结合金融业务特点,总结尝试在更多的关键业务场景实现NewSQL分布式数据库的落地实践,后续将进行以下三方面的推广和实践:

一是发挥NewSQL分布式数据库的技术特性,探索实现数据分析挖掘和业务联机交易的一站式解决方案,满足银行实时的数据分析和挖掘能力,了解业务开展真实情况,及时决策调整业务策略,提升数据治理能力更好地适应瞬息万变的互联网业务;

二是总结归纳金融领域分布式数据库应用的行业标准和规范,全场景进行分布式数据库替换,打破国外数据库技术的依赖,实现金融级数据库完全国产化;

三是探索利用NewSQL分布式数据库的容器技术构建一体式的数据库云平台,实现快速交付、动态伸缩的数据库及服务,消除数据库技术的复杂特性,提高IT服务的快速交付速度,打通提升IT服务能力的最后一公里,为分布式数据库在金融领域的全面应用提供可参考的实践借鉴和成果。


0
相关文章