案例参考 银行分布式数据库应用实践.docx

《案例参考 银行分布式数据库应用实践.docx》由会员分享，可在线阅读，更多相关《案例参考 银行分布式数据库应用实践.docx（7页珍藏版）》请在三一办公上搜索。

1、银行数据库面临的主要问题我行IT系统长期以来一直使用DB2、Oracle等传统数据库作为存储和处理工具，随着业务日益增长以及线下向线上的转移，传统数据库逐渐暴露出一些问题：如高并发下处理能力瓶颈，单机硬件故障或者软件升级导致服务停止，应用和数据多活部署，数据库调优、问题诊断和故障排查等。而且，原厂服务成本高,小微金融服务代价大，长期很难坚持。随着近年我行线上交易大幅增长，特别是“双十一”等瞬时交易井喷，传统架构和现在新的业务及技术需求矛盾越来越突出。一直以来银行也在思考关键业务如何实现传统架构转型，提升系统处理能力，同时兼顾实现自主可控要求和降低成本。经过行领导和行内技术专家团队的分析,我们决

2、定从分布式数据库入手,选择技术上完全安全可控，完全原生的分布式数据库，而且最好有大型商业银行的关键交易业务案例的厂商。单机处理性能瓶颈信息泄单机故障图1现有商用数据库问题国产分布式数据库选型目前，分布式数据库解决方案已经呈现百花齐放的态势，如何选择合适的分布式数据库又成为困扰决策者的一个问题。从技术角度看，分布式数据库解决方案大致可以分为两大类，即分布式数据库中间件和原生分布式数据库。分布式数据库中间件是架构在多个传统单点数据库系统（比如MySQD之上的中间层解决方案，通过将数据分拆到不同的数据库节点上，利用中间件来管理和访问各个数据库中的数据，通常需要用户参与到数据分拆和节点管理过程中。原生

3、分布式数据库是指从架构设计、底层存储和查询处理均面向分布式数据管理需求，数据库集群作为一个整体对外提供服务，用户无需关注集群内部的实现细节。相比较来说，原生分布式数据库在产品技术上和自主可控程度上优势明显一些。我行把数据库技术实现架构、稳定性、技术保障、开发易用性、运维简便低成本、二次学习成本，以及具有大型银行关键业务案例作为国产分布式数据库主要的选型指标。经过充分调研、考察、技术交流、测试，上海丛云科技的Kingwow（金乌）数据库优势逐步显现：Kingwow是原生分布式架构，能够成熟解决传统单点处理瓶颈；没有单机故障，数据多副本冗余存储，实现PaXoS协议，并保证分节点发生故障时系统在10

4、秒内自动恢复服务且不丢失数据；实现在线一键横向扩展能力，提升系统的处理能力。此外，Kingwow对于应用开发几乎透明，而且运维也简单，对我们体量较小的城商行来说，科技投入有限，这些优势非常有针对性和吸引力。鉴于以上对Kingwow的深入了解和各项指标POC测试，Kingwow的技术优势越来越明显，我们决定使用Kingwow数据库。分布式数据库的应用试点我行年初决定在网联支付系统中首次尝试使用Kingwow分布式数据库。网联支付目前主要承接从第三方支付发起的收付款业务，经网联清算平台，转发至银行（见图2）。目前我行对接支付宝、财付通、京东等主要的第三方支付机构,涉及客户交易每日数百万笔，交易金额

5、上亿。支付宝财付通网联清算中心图2网联支付系统架构图网联支付系统在应用开发过程中，Kingwow不需要开发人员进行分库分表及SQ1.语句改造，基本做到和传统数据库的兼容。由于是新建系统，没有数据迁移压力，整个过程非常顺利。我行网联支付系统于6月顺利上线，截至目前，系统处理性能高、运行稳定、效果良好。在网联支付系统上线成功的基础上,我行继续选择历史库系统扩大KingWOW应用试点。原先我行历史库系统主要使用HadOOP生态产品，面临几大问题：一是应用开发SQ1.支持有限，对应用开发人员不友好；二是实时响应较慢，特别是系统批量时，资源非常紧张，影响对客联机查询交易效率；三是不能支持事务,对于一些历

6、史数据的修改会面临事务支持的问题；四是技术支持力度不够，一旦出现技术问题，无法保证能够及时解决。因此我行将历史库逐步迁移到Kingwow数据库（见图3）,并于2018年10月投产上线，整个系统运行也非常平稳。网银柜面手机银行图3历史库系统架构图有了网联支付和历史库的Kingwow数据库成功的使用经验，年我行继续扩大国产数据库试点，将超级网银数据库迁移替换为KingWOW数据库。超级网银（见图4）,是目前跨行资金100万以内的主要支付通道，该系统对交易的稳定性要求很高，人民银行每日都要监测各行的响应率。经过双方技术专家紧密配合,超级网银也于年月正式投产。系统上线后，数据库运行稳定，年我行的超级网

7、银响应率在5个9以上，成效非常明显。图4超级网银系统架构图信创工作总结和规划银行在年启动国产商用分布式数据库的选型和引入，到目前为止，已经在多套重要交易系统中成功使用。在当前复杂、严峻的时代背景下：当时我行的决策非常适时，也为业界联机交易数据库信创改造提供了可借鉴的成功经验。同时，我行科技人员掌握了分布式架构和数据库的相关专业知识，使得我行在技术积累和使用上紧跟技术发展潮流，并在局部方面的创新走在行业前列。现阶段我行在国产数据库KingWOW的使用过程中，其核心功能和特性非常不错，使用习惯和原数据库差别甚微，学习及使用成本非常低，对于应用开发和运维工作，我行技术人员基本都能够掌握和独自承担。当

8、然，Kingwow数据库在外围配套工具和生态建设方面还需要进一步优化。希望未来国产数据库在这些方面迎头赶上、甚至弯道超车，增强用户的使用信心。下一步，我行将立足于自身的实际情况，结合国家的信息安全战略要求，稳步扩大分布式数据库的应用范围，加快数据库信创改造进度，在人民银行和银保监会要求的时间计划之前完成我行信息系统的信创改造工作。实例：中小银行关键业务系统分布式数据库实践近些年金融行业IT技术架构更新迭代快，发展迅速，分布式架构已经成为主流，像云平台、大数据、A1.微服务、分布式架构、敏捷前台、统一中台等技术架构的发展很好地契合了金融行业未来业务发展的需求，而数据库作为其中重要环节贯穿了整个前

9、中后端，重要程度越来越高。此外，受复杂多变的国际形势影响，金融行业自主可控越来越迫切，信创工作逐步进入深水区，数据库也成为一项重要基础研究和应用。本文以我行新核心系统采用分布式数据库的探索和落地过程为主线，分析和总结分布式数据库模式在中小银行核心等关键业务系统应用经验，希望对千亿级中小银行分布式数据库的推广落地提供一定借鉴意义。核心系统应用实践从年起，我行一直对分布式数据库进行探索及实践。年，我行对中间业务等外围系统先行试用分布式数据库，验证可行性并积累相关经验。年月我行在传统核心系统使用分布式数据库，成为首家案例。而后，开展了规模推广和全栈信创环境适配，核心、信贷、渠道、票据等几十套关键业务

10、系统逐步迁移到分布式数据库。同时，年我行顺利投产全栈信创分布式数据库集群环境。我行新一代核心系统项目建设周期一年，于年月日上线，核心系统硬件设备采用通用服务器，在应用层面采用基于ARM架构的信创服务器，数据库采用分布式数据库作为新核心数据库，运行至今，一直保持较好的稳定性和高效性。1 .总体架构我行新核心系统分布式数据库采用“两地三中心部署，根据业务需求将业务数据进行分片，每分片采用“一主三备模式部署，同步模式采用“同机房异步，异机房强同步”模式，以实现跨机房数据无丢失。分布式数据库由计算节点层（图中指接入网关）、存储节点层（图中指数据库）和管控节点层（图中指管理组件）组成，计算节点层主要负责

11、应用系统的接入和数据计算，存储节点层主要负责实际数据的存储更新和主从同步，管控节点层负责集群的管控，全局事务的管理，主备切换，故障隔离与恢复，监控和自动化运维相关事宜。图某行核心系统分布式数据库示意图计算节点层采用多节点、高可用部署，计算节点不存储数据，只进行数据计算和结果返回，所以单节点故障不影响其他计算节点运行。同城两机房计算节点均部署N台（N由具体业务量和计算量确定），同城两机房均可接入业务，同时实现节点级和机房级高可用，确保业务连续性。存储节点采取“一主多备”模式进行部署，存储节点数量M由业务量确定，同步模式采用“同机房异步，同城异机房强同步”模式，以确保跨机房数据一致性,此外为减少机

12、房间链路抖动对同步的影响，同城异机房设置两个强同步节点并使用两种不同运营商链路。故障恢复方面，当主DB出现故障时，系统具备自动切换到备DB对外恢复业务的能力，通常在2030秒，时间太短可能造成性能高峰误切，时间太长会导致业务影响时间长，所以在设计时通常考虑RTOW30S即可。管控节点是需要三机房部署，我行仲裁节点部署在异地机房，当单机房出现故障时便于进行仲裁，防止出现脑裂情况。除管控节点外，异地机房还需要部署对应的计算节点和存储节点，与本地数据库实例进行异步同步，应用根据实际情况在异地机房部署。此外，为了控制实施风险，方案还提供了分布式数据库到传统集中式数据库的多源同步方案，极端情况可快速切换

13、到集中式数据库。目前这个集中式数据库已经完成了使命，不再被使用，现阶段方案制定时也没有必要制定此类兜底后备方案。2 .应用效果（1）性能方面。我行新核心采用N台计算节点（接入网关）服务器+M台存储节点（数据库）服务器直接承载业务（图1中红线所示业务流），在5000万账户性能测试中，可以实现每节点1500+TPS的极限性能（核心系统整体极限性能主要与DB节点数M有关。例如，当M=4时，我行实测极限性能可达到6000+TPS）,并且具备横向可扩展性，通过增加计算和存储节点实现性能和容量的在线扩展。新核心实际运行指标也一直比较稳定和高效。日常交易高峰时，系统CPU和IO等负载均在3%以下，一直处于轻

14、载状态；高频查询类交易耗时100毫秒左右（查询类交易单次交易应用与数据库之间的交互次数平均在80次左右），高频账务类交易耗时300亳秒左右（账务类交易单次交易应用与数据库之间的交互次数平均在250次左右），业务交易中，应用与数据库之间的一次交互耗时接近1毫秒，较为高效；批处理方面，新核心日终跑批耗时17分钟，每季度结息日存贷款结息付息耗时16分钟，年终结算日年终结算步骤耗时2分钟。（2）成本方面。以核心为代表的关键业务系统，如果采用传统集中式架构,需要采用高端大机或者小型机，高端存储和存储双活，成本高昂，而分布式数据库方案全部采用通用服务器，因此其成本优势明显，我行根据通用架构对集中式数据库和

15、分布式数据库硬件投入进行了初步测算，采用分布式架构硬件投入可以节省70%甚至更多，后期的维保费用也较低。对于一般业务系统，由于集中式数据库也可以采用通用服务器和中低端存储，因此分布式数据库的硬件成本优势不明显，经过我行测算，两者硬件成本基本相当。此外，数据库软件授权由于商务差别较大，没法做量化对比，但授权费用总体来说分布式数据库相对集中式成本要低。（3）安全稳定方面。新核心系统上线后，我行进行了灾备机房全量接管演练，模拟中心机房整体故障情况下（比如断电、网络故障等）灾备中心能够接管全量业务继续运行。通过参演人员密切配合，有效沟通，演练全程顺畅有序，所有参演系统做到了无缝平滑切换，切换后系统运行

16、稳定，演练工作圆满完成。我行全量核心业务在灾备机房全量运行了3天后顺利回切中心机房。（4）自动化运维方面。分布式数据库提供了较为完备的自动化运维平台（运维+诊断），可以完成绝大部分的自动化运维操作，极大提升了运维人员的工作效率。经验总结分享而过:余实最我行分布式数据库应用从无到有、从核心到外围、从部分信创到全栈信创，在关键业务系统的探索和落地过程中不断总结经验，现将相关经验总结如下。1 .选型考虑分布式数据库的技术优势和成本优势明显，契合未来数字化转型趋势，是现阶段金融行业解决数据库卡脖子问题的一个切实可行的可替代方案。分布式数据库产品处在“百花齐放、百家争鸣”的时期。有基于开源内核的，有纯自

17、研内核的；有计算存储紧耦合，有计算存储分离；有的擅长交易型O1.TP,有的擅长分析性O1.AP,也有支持混合负载HTAP的等。然而，现阶段很难找到一款产品能够适合所有业务场景，所以选型需要结合具体的业务场景，建议考虑以下因素。规划先行：选型要契合未来业务发展和数字化转型发展规划，行内未来重点建设的项目，必须能够适配此类数据库。选择能满足大部分业务场景的数据库，建议选择偏O1.TP型数据库，对于O1.AP型可以单独选型，也可以选择HTAP型数据库。落地很重要：这个从。到1的过程意义重大，建议选择关键业务系统，不要选无关紧要的系统；建议优先选取互联网金融类业务（例如聚合支付、手机银行、网上银行、直

18、销银行等），此类系统比较具有代表性，通常都会采用微服务架构,数据层面可以以客户账户维度进行划分，业务场景不算复杂，跑批类需求较少，相对改造的难度可以接受。银行核心系统改造讲究时机，结合行内情况开展预研和可研，核心系统升级替换优先采用分布式数据库。除了业务场景考虑外，还要考虑产品和厂商相关因素，如下。实施案例：数据库产品行业应用情况，是否有银行核心应用案例。厂商情况：研发团队和产品后续演进计划；实施和运维团队实力，对本项目的资源投入情况。产品POC测试情况：基本功能指标、ACIDMVCC高可用容灾、横向扩展性、高并发和并发控制、其他性能指标、与集中式数据库兼容情况、安装部署运维情况、产品手册完善

19、情况等。成本投入：建设和运维成本投入，后续扩容投入。信创生态：信创芯片、信创服务器、信创操作系统、信创中间件以及信创负载均衡等信创生态支持情况，数据库厂商信创的资源投入情况等。监管政策导向和行内决策层的支持起到了非常关键的作用。2 .难点问题分析（1）分布式数据库与传统集中式数据库兼容问题。分布式数据库与传统集中式数据库存在的语法兼容性的差异，是适配改造过程中工作量最大的部分。一方面需要对字段类型、SQ1.语句等进行适配改造，另一方面还需要对一些特殊数据库对象（例如存储过程、序列）进行优化改造，全面适配分布式数据库。（2）分布式数据库数据分布对性能的影响问题。集中式数据库数据集中存放，分布式数

20、据库对外是一个逻辑库，内部数据实际是分节点存放。原本适配集中式数据库的应用架构直接应用到分布式数据库，由于数据分布的差异，无法充分发挥分布式数据库高性能和可扩展的优势，甚至会导致性能不如集中式的情况。因此，适配时需要充分考虑数据分布对性能的影响，做好数据切片规划，以达到最优性能。首先，在新建表时要充分考虑表容量规划、合理选择表类型和表分区键，尽可能减少表关联和数据节点间数据的横向流动，提升查询效率；其次,对业务SQ1.语句进行持续优化，通过表关联拆解、结合广播表或者临时表优化关联、增加冗余关联字段作为分区键、业务重构等方式进行持续优化。（3）分布式数据库一致性问题。正是由于数据的分散存储，相对

21、于集中式数据库实现一致性的先天优势，分布式数据库的一致性实现难度较大，而金融行业对数据一致性的要求是非常高的，因此在适配改造时需要重点考虑和验证一致性的问题。一致性问题从主备一致性、分布式事务一致性，以及全局一致性三个方面进行了全面的论证和验证，我们通过多轮专家论证、性能测试、业务测试以及极限破坏测试等充分验证了分布式数据库一致性的问题，以满足我行核心等关键业务系统一致性需求。（4）分布式数据库与信创相关适配问题。分布式数据库、信创操作系统、信创芯片（尤其是ARM架构）以及信创服务器之间的适配难度和复杂度较高，每种组件都是“新东西”，把它们组合在一起难免会出现各种层面的“新问题”，再加上各组件

22、更新迭代速度较快（尤其是数据库和操作系统），进一步增加了验证难度，因为这类问题比较难以排查定位，处理的效率也得不到保障，需要行业侧和产业侧共同去推动。尽管适配难度较大，中间也遇到并处理了不少适配问题（例如分布式数据库与信创操作系统适配时磁盘IO资源无法充分使用影响整体性能的问题），但是我行依然积极推动分布式数据库全栈信创化建设，部署大量业务系统进行生成环境验证，积累相关经验，希望能在行业内起到一定借鉴作用。写在最后本文介绍了我行分布式数据库在关键核心业务系统的落地方案和经验，尤其是新核心项目充分验证信创分布式数据库在核心系统应用的技术可行性，为中小银行核心交易系统搭建安全可靠的底层数据库提供可行的解决方案，为千亿级中心银行在信创分布式数据库的应用以及全栈应用方面提供经验借鉴，为金融行业重要系统的信创建设提供优秀参考案例。