分布式架构或可解决数据库成本问题，银行业该如何玩转？

数据库是银行业务系统的核心组成部分，随着业务的快速发展其在扩展性、业务连续性和成本方面的问题逐渐凸显。一是传统数据库使用Scale-up方式实现性能及容量扩展，此方式受制于单个硬件设备支持的最大容量，且影响业务连续性，难以应对业务的快速发展。二是传统数据库厂商核心代码的开发维护在国外进行，使得国内数据库用户在技术支持和故障处理方面沟通成本高、效率低。在支付场景无处不在的今天，这样的服务已经无法满足业务连续性要求。三是产品成本高昂，用户缺乏议价能力，对于提倡“节约化经营”的今天，这样的商务模式已不符合银行业自身成本控制的需求。
 
随着闪存系列高性能存储介质的发展和互联网公司在分布式数据库方面的尝试，使用分布式数据库和本地存储解决银行的问题成为可能。但由于对数据一致性可靠性要求不同，互联网公司的分布式数据库产品无法直接用于银行业务，只能根据银行业务特点研发强一致性的分布式数据库。
 
分布式数据库架构创新
 
我们针对银行业务的特点，创新性地引入新型分布式事务处理方案，在保证数据安全一致前提下，通过无共享（shared nothing）的架构实现数据库容量和性能的水平扩展，并在以下几个关键技术上取得突破。一是提供了完整的分布式事务解决方案，具备数据库的ACID 特性，保证系统的处理效率、跨节点数据的强一致性及分布式事务对应用的透明性。二是既支持标准的SQL 语法，降低存量应用迁移成本，又创建了分布式SQL 语法集，充分发挥分布式数据库的优势。三是提供运行态数据重分布解决方案，热点数据迁移秒级停机，实现容量和性能的快速扩展。四是保证数据高可靠、服务高可用，单节点的硬件故障不造成数据损坏，不影响服务的正常使用，且提供完整的同城和异地容灾方案。五是提供多租户服务，保证多个业务系统间服务统一、数据隔离、访问隔离、用户信息隔离。分布式数据库整体架构如图1 所示。
 
 
架构在客户端接入层、前置中间件集群、数据库集群三个层次上可横向线性扩展，满足性能及容量的各种处理需求；客户端接入层负责SQL 组装、连接池管理和负载均衡；前置中间件集群支持SQL 解析、优化、自动路由分配；数据库集群负责数据的存储和本地事务处理。
 
分布式数据库关键技术分析
 
1. 分布式事务处理。分布式数据库要想实现数据的实时一致性，必须解决分布式事务控制问题。目前业内实现分布式事务控制主要有基于XA 协议的两阶段提交方案、基于消息队列的异步处理方案和基于全局GTID 事务控制三种方案。
 
（1）基于XA 协议的两阶段提交方案。优点是比较均衡地实现了分布式事务的大部分设计原则，可以利用现存的技术成果，但存在交互次数多、日志刷新次数多、无法解决分布式死锁、不能有效提供隔离性等诸多问题。这些问题从不同层面影响了分布式事务的高效性和并发性。
 
（2）基于消息队列的异步处理方案。基于消息队列实现的异步事务是通过牺牲分布式事务的一致性和隔离性，以获得高并发访问支持的最终一致性设计方案。其思路是将分布式事务涉及的过程按照节点和逻辑分解成多个子事务或子过程，每个子事务独立实施，并确保其一旦成功建立后，定会全部实施成功。优点是能大大提高系统的并发处理能力，在互联网应用中得到广泛验证，但其存在对业务实现难度大、分布式死锁无法解决、一定时间窗口内数据不一致等不足。
 
（3）基于全局GTID 的事务控制方案。基于全局GTID实现的分布式事务控制是通过为每个分布式事务分配一个单调递增的全局事务ID，并通过这个唯一的事务ID 判断、协调分布式事务在不同节点之间的状态，以实现事务一致性的方案。在该方案中，分布式写的原子性、一致性、隔离性和持久性通过全局事务管理器加乐观锁获得。中信银行的分布式数据库采用的就是这种事务控制方法。
 
分布式事务的一致性控制必须与隔离级别结合，才能确保数据的一致性。在支持传统关系型数据库的脏读、已提交读、可重复读、串行化四个隔离级别之外，针对分布式的特点，我们还新增了弱一致性读和单事务写两种读写的隔离级别，分别针对不同的场景优化读写的效率，可以较好地提升分布式事务处理性能。考虑到银行业务对强一致性要求极高、应用开发人员对传统数据库开发方式熟练的特点，基于全局GTID 的分布式事务控制方案对应用透明，事务强一致性，是符合银行业特点的最优选择。
 
2. 数据重分布处理。分布式架构下节点扩展是数据扩容的常用手段，为充分利用新增节点的计算和存储资源，需要对原有节点的数据进行重分布。其难点在于减少对外部服务的影响，首先是减少停止服务的时间，其次是降低重分布时对外部请求响应时间的影响。目前业内主要有两种重分布策略。
 
（1）预分区策略。在初始建库时建立固定数量的分区，扩容时在新增节点与待扩容节点之间建立复制关系。当数据基本一致时锁表暂停写操作，数据完全同步后修改分布策略完成重分布，后续异步删除多余的分区。这种策略实现较简单，但重分布粒度只能限制于分区级，适用于可以预先估算数据规模及分布情况的场景。
 
（2）临时表策略。是针对要重分布的表，建立一个和原表字段结构相同但为新分发策略的临时表，将数据从原表导出成文件，再将文件导入到临时表。导入过程使用新分发策略，存量数据导入完成后，通过binlog 回放实现增量数据的重分布，最后锁表切换临时表和原表完成重分布。这种策略对重分布粒度没有限制，但数据导入导出对性能有一定影响，且需要额外开发分布式数据导入导出及增量binlog 分发功能。
 
我们综合了两种策略的优点，当数据规模可以事先规划时采用预分区策略，而当需要对特定分区进行分裂或合并时，则通过第二种策略完成更细粒度的数据重分布。
 
分布式数据库应用案例
 
由于分布式数据库自身具有较高的技术难度，在应用过程中我们遵循“审慎试点、逐批推广”的原则，先后在冠字号码信息管理系统、中信银行新门户、金融同业平台和零售积分系统中对分布式数据库进行试点应用，取得了良好的效果。我们以零售积分系统为例介绍分布式数据库的使用。
 
零售积分系统是一套全新的业务系统，实现中信银行零售客户综合积分的统一管理。零售客户积分需要在交易明细这个级别进行统计，数据量非常大，以积分数据保存1 年计算，交易明细都要几个亿数据量。而且在积分消费之后需要对相应的交易明细数据进行逐笔更新操作，对数据库的处理能力要求很高，非常适合分布式数据库。
 
积分的转让与消费则与典型支付流程相似，为提高性能，我们对数据进行了分片，通过分布式数据库实现了积分实时累计和实时消费；通过积分转让和批量积分修改实现跨节点的分布式交易，提升业务性能并有效降低了业务复杂度。在实际运行过程中，由于不同地区可能有不同的促销活动，有可能造成数据倾斜或热点，因此分布式数据库做到了动态数据重分布，在不中断业务的情况下能够重新分布数据使得热点和数据量在多个节点均匀分布。
 
对于非实时性的积分，我们利用大数据平台进行T+1 的积分计算，并批量方式更新到分布式数据库中，由分布式数据库提供个人客户的积分查询、消费服务。
 
作者：陈蓓（中信银行信息技术管理部副总经理）、刘文涛（中信银行软件开发中心）
 
来源：《金融电子化》

来源：

来源：中币网  https://www.zhongbi.net/news/blocknews/24377.html
声明：登载此文仅出于分享区块链知识，并不意味着赞同其观点或证实其描述。文章内容仅供参考，不构成投资建议。投资者据此操作，风险自担。 此文如侵犯到您的合法权益，请联系我们3111859717@qq.com，我们将第一时间处理。