案例银行分布式数据库应用实践 附分布式数据库在金融应用场景中的探索与实践分析.docx

《案例银行分布式数据库应用实践 附分布式数据库在金融应用场景中的探索与实践分析.docx》由会员分享，可在线阅读，更多相关《案例银行分布式数据库应用实践 附分布式数据库在金融应用场景中的探索与实践分析.docx（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、信息安全是国家安全的重要组成部分，已经上升到与政治安全、经济安全、 领土安全等并驾齐驱的战略高度。随着近年来移动互联技术日益更新，我国信息 安全形势日益严峻！中央网信办、工信部、国家发改委、人民银行、银保监会等 都提出了信息技术的安全可控要求。对于银行业来说，为提高信息技术安全可控 能力，加速推进国家信息安全战略；应构建“有管理、可控制”的技术体系。同 时，网络和移动计算的快速发展创造了一个新的数据时代，线上交易和热点交易 突发，对传统IT架构特别是数据库造成了较大的冲击与挑战，与此同时也带动 了新型分布式数据库管理系统的兴起！银行数据库面临的主要问题我行IT系统长期以来一直使用DB2、Ora

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

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

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

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

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

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

8、19年11月正式投产。系统上线后，数据 库运行稳定，202（）年我行的超级网银响应率在5个9以上，成效非常明显。图4超级网银系统架构图信创工作总结和规划银行在2018年启动国产商用分布式数据库的选型和引入，到目前为止，己 经在多套重要交易系统中成功使用。在当前复杂、严峻的时代背景下：当时我行 的决策非常适时，也为业界联机交易数据库信创改造提供了可借鉴的成功经验。 同时，我行科技人员掌握了分布式架构和数据库的相关专业知识，使得我行在技 术积累和使用上紧跟技术发展潮流，并在局部方面的创新走在行业前列。现阶段 我行在国产数据库Kingwow的使用过程中，其核心功能和特性非常不错，使用 习惯和原数据库

9、差别甚微，学习及使用成本非常低，对于应用开发和运维工作， 我行技术人员基本都能够掌握和独自承担。当然，Kingwow数据库在外围配套 工具和生态建设方面还需要进一步优化。希望未来国产数据库在这些方面迎头赶 上、甚至弯道超车，增强用户的使用信心。下一步，我行将立足于自身的实际情 况，结合国家的信息安全战略要求，稳步扩大分布式数据库的应用范围，加快数 据库信创改造进度，在人民银行和银保监会要求的时间计划之前完成我行信息系 统的信创改造工作。分布式数据库在金融应用场景中的探索与实践分析摘要：网络金融持续发展，对金融业数据库方面要求日益提升，迫切需要 具备高可用性、可扩展性、高性能的数据库系统。鉴于此

10、，本文主要围绕着在金 融行业应用场景当中分布式的数据库应用探索及实践，望能够为相关专家及学者 对这一课题的深入研究提供有价值的参考或者依据。关键词：分布式;数据库;金融;应用场景；1、系统整体框架1.1 框架分布式的数据库（CBASE）,整个系统框架以四个系统功能模块为主，即为 集群管理、事务处理、数据存储、SQL处理。集群管理，管理集群全部服务器、 副本与数据分布;事务处理，相应各种更新操作、更新存储系统内部增量数据;数 据存储，储集群基准的数据;SQL处理，接受、解析用户端SQL的请求，经语法、 词法分析、查询优化各项操作，发送至数据存储或者事务处理的节点来执行。1.2 关键性的技术模块写

11、性能方面的优化CBASE的设计，可实现读写相互分离的一种系统框架，对读或者写负载有 所不同，予以分别优化处理。针对未修改数据，通过普通的PC服务装置，实现 存储操作，处理大量数据扩展管理方面的问题。更新的热点数据被存储至内存较 大的事务处理节点，事务处理的节点内存达相应大小后，能手动或自动冻结数据， 并将其存储至固态的硬盘内部，以定期合并形式把数据分散地存储至静态的数据 节点内部。通过这一设计，可维持系统的可扩展性，且对事务处理的请求有着高 吞吐量。多数事务处理均无需跨越相应事务处理的节点，可借助事务处理增加节 点这一手段将系统整体处理能力提升。针对少量分布形式的事务，仅经优化两个 阶段，便可

12、将降低事务的延迟提交。事务处理的节点，通过大容量的内存数据， 规避掉传统的数据库内集中式锁管理装置，改用轻量级别多版本、行锁并发的控 制协议、混合存储的介质存储相应日志等各项科学技术，系统整体能力得以有效 提升。高可用性能CBASE当中实现分布式的选举协议状态转换，属于不确定性的有限自动装 置。阶段角色会伴随选举实随时变换。某个节点在刚刚启动或者从故障当中恢复, 角色处于备节点状态，会设定时装置。若此节点已接收主节点所发送更新的日志, 定时装置会重置，角色处于恒定不变状态。反之，则定时器在超时之后，认为集 群未存在有效主节点，此节点便会转变成候选者，并准备竞争成全新主节点。候 选者会向其余节点

13、传输投票的请求，有三种情况，即为获取到多数节点的投票节 点属于主节点;受到更新的日志信息，证明集群当中主节点已存现，候选者们可 转变其备节点;若选举己超时，则需重新发起新一轮的选举。节点逐渐成为了主 节点过后，会向其备节点来发送相应更新日志,将其余节点定时器予以重组处理。分布式的事务事务处理，属于支撑着金融业应用一项关键的科学技术，可保证业务数据一 致与完整。大型的银行应用不但要满足数据库方面系统完整度要求，还应具备着 网络级并的事务方面处理能力。金融业务内部系统的事务处理实际应用特点是， 通过CBASE来实现支撑着高通量的事务处理分布式的一种数据库综合系统，相 比原有集中式的数据库，CBAS

14、E并不需要用户设计及维护分库的分表规则，该 系统能自动化结合主键，把数据合理划分成不同事务的处理节点，业务逻辑及数 据存储的解耦合即可实现，开发及维护方面的难度系数得以有效降低，资源线得 以扩展，且集群解决了 I/O上限方面现实问题。CBASE分布式的事务引擎具体 实现期间，通过两阶段的提交优化处理，事务可保证有着一致性方而特征。无故 障期间，可轻松实现此协议。若有故障问题出现，比如网络故障、信息丢失等等, 通过超时动作便可避免进程无限性的阻塞，协议实现后，进程会阻塞每步骤，且 均会加入相应超时动作。处于最坏情况之下，执行两个阶段的提交协议，期间可 能会有多次的服务器或者通信故障问题出现，导致

15、参与者无法较长时间的停留至 不确定的状态中，即为未解决事务。而同分布式的数据库，便能够恢复持久存储 的信息内容对象值，若参与者为不可用状态，则可等待着数据库的管理技术员加 以干预或处理.2、实践应用2.1 查询历史数据伴随着时间逐步推移及业务持续发展，各企业内部历史数据的查询系统均面 临着历史数据信息量持续增长、系统框架当中传统的数据库已无法满足于快速增 加的数据量现实需求。金融业历史数据有着较广的涵盖范围，如交行历史数据的 查询系统，内含主机、账务、贷记卡等业务系统所有历史数据，对数据库自身扩 展性方面有著极高的要求，以能够充分满足于业务量现实需求。除了历史数据方 面存储，查询历史数据系统还

16、应当向外部提供着联机事务检索与各种新增业务服 务等，缓解其余在线业务历史数据的管理压力，以至于对数据库快速响应着联机 检索服务方面有着极高的要求与标准。历史数据的查询系统，要求该数据库应当 具备着较高的可扩展性、可靠性、高性能等，且该分布式的数据库还应当充分满 足于各方面现实标准与要求。经大量测试与评估分析后，交行历史数据库的综合 系统内采用了 CBASE,现阶段系统整体的数据量可达上百个TB,每日均超1 个TB,且有持续增长这一变化趋势。大并发检索条件下，检索相应的时间可维 持毫秒级别范围。经多年稳定运行可充分表明自主研发分布式的数据库在金融领 域中应用切实可行。2.2 贷记卡专项授权系统的

17、并发处理信用卡相关业务不断纵深向的发展及客户量持续增长，以至于交易量极具攀 升，对于贷记卡的授权系统在线升级更新、持续高效、7*24h的稳定化交易服务 方面更为迫切。伴随网络金融出现与广泛应用，支付宝相关电商双11的网购促 销均引起交易呈爆发式的增长，系统负担逐渐加重，传统的数据库迎来了空前绝 后的、史无前例的发展挑战，原有系统资源已无法满足现实需求，数据库整个系 统自身潜在各项性能发展瓶颈。那么，为确保贷记卡的授权系统稳定，将系统总体处理能力提升，基于原有 系统框架，借助CBASE分流处理高并发的业务所形成系统压力。以CBASE为 基础新一代的贷记卡专项授权系统基本特征如下：高并发的处理能力

18、，可高峰每 秒处理事务量达上万;弹性的扩展能力，整个系统处理的能力能实现快速弹性的 扩容处理;高可用性，能够确保业务系统维持7*24h以内在线服务，分流高并发 时主机的压力。在银行各个关键系统的试点期间，CBASE框架已逐步成型，各项功能得以 逐步完善化，可靠性与各项性能均得以增强，己向着产品化的方向发展着，所取 得经济与社会方面的效益较为显著。以某商业银行为例，通过采用了以CBASE 为基础新一代的贷记卡专项授权系统后，构建起了数据库在授权系统，通过采集 海量信息，存储主数据库内，依据不同信息安全等级，对不同用户进行分级别授 权，以更好地保护用户信息，增强以CBASE为基础新一代的贷记卡专项授权系 统整体安全系数。3、结语通过以上分析论述之后我们对于金融行业应用场景当中分布式的数据库应 用情况，均能够有了更加深入地认识及了解。从总体上来分析，分布式的数据库 具备着强大的应用优势，今后为能够更好地将其应用至金融行业的应用场景当 中，便还需相关技术员结合实际情况，加以分析与研究，持续优化与完善该分布 式的数据库，以便于其充分发挥效用科学应用至金融行业各种应用场景中，为金 融行业发展注入力量。参考文献：“1张文升.分布式数据库Greenplum研究与应用J.金融科技时代，2017, 19 (06)： 444-446.