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

《NewSQL分布式数据库在银行场景的实践.docx》由会员分享，可在线阅读，更多相关《NewSQL分布式数据库在银行场景的实践.docx（10页珍藏版）》请在第一文库网上搜索。

1、NewSQ1分布式数据库在银行场景的实践【摘要】在金融领域，绝大多数的银行业应用设计都是基于传统单机关系型数据库，没有从整体应用架构考虑与第三代分布式数据库进行适配，尤其在银行核心系统应用第三代分布式数据库案例甚少，没有可复制的成功经验可以借鉴，面临的挑战主要有两个方面，分别是数据库自身的机制问题和核心系统应用的复杂度和差异性挑战一、项目背景随着新一代信息技术在金融领域的蓬勃发展，科技与金融业务不断融合，为金融行业注入新的发展活力，使科技成为金融高质量发展的“新引擎”。数据库作为IT基础设施最关键的组件之一，广泛应用于银行业务系统，目前在我国IT基础设施领域银行业金融机构多数依赖于国外数据库产

2、品，未能真正实现技术安全可控。其中，银行核心系统作为对事务强一致性、高安全性、高稳定性要求最高的金融联机交易场景，其国产化进程将成为IT基础设施自主国产化的最后一公里，也将是国产数据库产品成熟度最有力的证明。某某银行成立之初，选择Mariadb技术路线，选型考量是产品的开源性和公立性，作为一家银行，数据安全也就是客户资金的安全，MariadbGa1eraC1USter强同步机制是考虑的关键点，我们在系统建设阶段制定了严格的数据技术标准和配置规范、统一使用MySqI协议，禁用存储过程，规范SQ1语法，限制事务大小等措施进行数据库的标准统一，但是随着业务规模的发展，Mariadb数据库带来了复杂性

3、、性能和容量方面的挑战。为了解决这个难点，我们开始在一些支付系统上尝试采用分库分表数据库架构，来解决业务量增长带来的数据库性能和容量问题，但是解决了老问题又来了新的问题，多实例分库架构带来了应用侵入和全局一致性等问题，这些问题只能从应用层面通过代码去解决，这样就增加了研发成本。同时给运维工作也带来了复杂度，首先分库分表架构的扩容是一个庞大的工作量，再者DD1变更操作也需要在业务量较小的时间段来执行，为了面对以上问题，我们开始考虑有没有一种新的数据库架构能解决以上所有问题。二、数据库架构选型分析数据库从其主要实现方式、技术架构和优势特点等方面可以分为以下三代：1第一代传统单机关系数据库传统单机关

4、系型数据库架构主要通过主备机方式实现数据的高可用性，以Orac1e、DB2等国外知名产品为主要代表，是目前国内大部分银行业关键交易场景的支撑技术。传统单机关系型数据库无法做到线性的性能扩容，其扩展方式只能采用垂直资源增加方式，无法横向扩展，其稳定性依赖于成本昂贵的的硬件设备，不能支撑快速增长的金融业务需求。2 第二代中间件关系数据库第二代中间件关系数据库采用单机数据库引擎与中间件代理层相结合的设计方式，实现了良好的水平扩展性，以第二代开源MySQ1分库分表架构为主要代表，主要应用于技术领先的互联网银行、直销银行的关键交易场景。目前，从互联网领域发展而来的第二代中间件关系数据库技术在行业应用中成

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

6、级事务交易。3 .第三代NewSQ1关系数据库NeWSQ1关系数据库采用内核级自动分片策略，结合高效分布式事务模型，是关系型数据库和NoSQ1数据库的完美组合。既可以实现水平线性扩展，又避免使用分片键，既保证了应用程序的使用透明，又极大降低了业务迁移中的工作量，是目前业界最先进的全分布解决方案，主流产品都是基于Goog1eSpanner论文衍生的产品。综合数据库技术的三代发展历程，我们考虑采用第三代NeWSQ1分布式数据库架构解决存在问题，在18年初开始测试了当时主流NewSQ1架构，我们选择支持MySq1协议的NeWSQ1架构，有以下几个方面考虑：（1）完全兼容mysq1协议，满足我们数据库

7、规范，应用适配成本较小；（2）分布式架构无应用侵入，解放了开发人员繁重的代码改造工作；（3）扩容工作将变的非常简单，轻松的增加服务器带来线性的性能提升，最重要的是支持dd1类在线变更，其实DBA大部分工作其实都是数据变更和提取，我们正在建设数据库自动化平台，计划和devops对接实现数据库自动化变更。（4）安全性和可用性考虑，本身采用raft的多数派协议，将节点部署不同地点就可以实现同城或者异地多活架构，还可以和mysq1数据库架构进行实时数据复制。三、银行应用场景分析及难点某某银行从18年就开始尝试NeWSQ1数据库架构，生产环境19年初最早在线查询场景进行了使用，技术储备一定阶段之后上线了

8、批处理业务场景，到19年10月上线了第一个真正的关键联机场景，互联网贷款系统，互联网贷款系统目前每天140OW日交易量，QPS日峰值9W次，总数据量达到8T以上。我们在联机场景已经上线了贷款业务场景、支付业务场景、核心系统目前也完成了应用适配，已经在生产环境并行上线试运行。银行核心系统是银行场景中AC1D特性要求最高的，也是典型的联机交易场景，在银行场景中对数据库成熟度要依赖性最强的应用系统，后续NeWSQ1在银行业务场景应用介绍，按照银行核心场景应用项目进行展开。与前两代数据库相比，NeWSQ1分布式数据库是关系型数据库和非关系型数据库的结合体，在架构和机制上都有很大的差别。在金融领域，绝大

9、多数的银行业应用设计都是基于传统单机关系型数据库，没有从整体应用架构考虑与第三代分布式数据库进行适配，尤其在银行核心系统应用第三代分布式数据库案例甚少，没有可复制的成功经验可以借鉴，面临的挑战主要有两个方面，分别是数据库自身的机制问题和核心系统应用的复杂度和差异性挑战。在数据库自身的机制方面，NeWSQ1分布式数据库在银行应用场景应用主要有以下几个问题：1、乐观锁适配问题。乐观锁在事前对表不会加锁，只在提交的时候比对提交版本号，不能保证每笔交易都能提交成功，在高并发的金融记账业务场景里，会造成大量的交易超时，出现用户短款现象，不能满足银行业务连续性和数据“强一致性”的要求。2、隔离级别问题。在

10、NeWSQ1分布式数据库应用过程中，由于原有银行核心系统的整体设计一般采用RC隔离级别，嵌套事务无法在RR隔离级别运行，需要对核心系统进行RR隔离级别的适配改造。3、串行机制问题。与传统单机关系型数据库相比，分布式数据库为保证所有节点的事务一致性，采用二阶段提交机制，其处理单个SQ1语句的执行效率较低，导致其整体性能反而没有传统单机关系型好，因此在分布式数据库应用设计时应尽量考虑并行机制，避免串行机制。在银行核心系统应用方面，NeWSQ1分布式数据库应用主要有以下几个问题：1、核心系统应用的复杂度。银行核心系统的业务逻辑复杂，与其相关联的系统众多，数据库又是其底层基础，进行NeWSQ1分布式数

11、据库适配将会对核心系统应用有很大的改动，也对应用适配提出了更高的要求。2、业务测试的差异性。在业务功能测试过程中，业务测试人员通常按照测试样例进行人工验证，并不能完全模拟生产环境下的业务交易，产品功能缺陷和代码BUG的风险仍然存在。四、分布式数据库在核心场景实践为了解决以上难点，某某银行深入研究NewSQ1分布式数据库在银行业核心系统的建设应用，妥善解决NeWSQ1分布式数据库产品在数据一致性、业务场景优化、数据迁移保障、并行上线验证等一系列的问题，我们主要完成了以下几个方面工作。第一是数据库适配性改造问题，主要是一些语法和功能性转换，包括格式转换，函数转换，伪列替换，还有就是采用java代码

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

13、观锁版本。第三是数据迁移问题，我们测试了三种方式，分别是kett1e全量+kett1e增量，优势是对应用侵入小，直接可以使用，缺点是增量需要停业务。第二种和第三种方式都使用了Ogg技术，Ogg需要数据库表有主键和唯一索引，对业务是有侵入性的，经过评估，为了保证现有生产环境稳定性，决定放弃Ogg技术，我们采用kett1e方式进行数据迁移，但是需要牺牲一定的停机时间。第四是性能测试阶段，测试的交易场景主要有动账类和开户类操作。主要遇到了以下几个方面问题。(1)读热点数据问题，大表读热点，在建表阶段通过手工方式通过热点打散机制将表数据平准分配到各数据节点。小表热点，只能通过CaChe解决，所以我们通

14、过应用层改造到到redis中解决。（2）交易链路长问题，分布式数据库单个SqI性能和单机关系型数据库有差距的，由于二阶段和多节点网络延时造成的，通过应用改造，将交易拆分不同小的原子并发处理。（3）事务隔离性问题，采用的分布式数据库是Si隔离级别，通过版本号控制提交一致性，在嵌套类事务，版本号冲突造成提交不成功，我们进行代码改造消除掉嵌套事务解决。（4）核心批量类交易，分布式数据库性能和原先的单机库库差不多，我们通过分析大部分时间都在逻辑运算，我们通过增加分布式数据库计算节点，可以线性的减少核心批量的执行时间。第五也是最难解决的问题，就是解决热点账户场景性能问题，主要有热点账户转账交易、非热点账

15、户转账交易、查询交易。在热点账户场景，这时候分布式数据库已经换成悲观锁版本，成功率已经可以达到100%,但是单次SqI执行效率低，热点账户由于存在单行的争抢，增加并发机制也提升不了tps,需要做应用改造解决。非热点账户和查询场景，没有行争取，应用通过增加并发机制，可以线性的提升tps。下面重点介绍下，针对银行核心系统热点账户场景的解决方案，热点账户其实在单机关系型数据库也有一些问题，在并发数高的时间，也存在一些超时，在数据库层面也很难解决，我们是通过应用改造解决的。首先我们对Sq1语句进行了优化，减少事务持锁时间，有一些效果，但是不能解决根本问题。接下来我们解耦贷款记账场景，将贷款业务实时记账

16、接口改成批量记账，通过日终汇总记账规避掉热点账户场景。贷款场景业务解耦示意图:但是支付和存款等其他业务场景热点账户问题目前还没有解决，我们通过应用将账户余额改造成多个子余额，在核心系统数据结构设计中，一个账户余额对应表结构的一行数据，我们通过子余额将账户余额改造成到表结构多个行，来分散行级争抢，通过4、8、16、32子余额扩展，可以实现线性的性能提升，在16子余额场景中，性能可以达到300tps,性能比目前生产库还提升了5倍左右，完美的解决了热点账户问题。账户子余额方案示意图：五、效果总结在银行多活核心系统上应用NeWSQ1分布式数据库，突破了原有数十年银行业核心系统数据库的IT建设模式，提升了银行业信息技术安全应用水平，推动了金融与科技的深度融合，打破了金融行业对国外数据库关键基础软件产品的依赖。同时，针对分布式数据库的特性，对应用架构、业务逻辑、测试方法进行了优化和创新，实现