暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

GoldenDB分布式数据库案例-中信银行实践分享


建设背景

中信银行现有系统大多在数据存储层都采用“IBM小型机+AIX操作系统+DB2数据库+高端存储阵列”的实现方式,随着业务和技术的发展,这种方式逐渐暴露出很多问题:

1.棱镜门事件后,监管机构从国家信息安全的角度对银行业的IT基础设施提出了开源化、国产化、自主掌控的要求,而传统数据存储层的实现方式明显和监管要求相背离。

2.面对利率市场化的挑战,银行业也面临着日趋严重的IT成本控制压力,而基于现行数据存储层的实现方式,每个系统的数据存储成本都数以百万计。

3.数据存储层缺乏良好的可扩展性,难以应对应用层的高并发数据访问,随着数据量的增长该问题日益突出,在电子银行渠道体现得愈加明显。

4.受限于现阶段银行IT实施商的人员素质和代码管控手段,应用实施过程中数据存储层代码质量普遍不高,是现阶段生产问题频出的主要原因之一。

2014年中信银行最终选择中兴通讯作为合作伙伴,开始启动分布式数据库的研发,产品定位直指两大核心(总行核心和信用卡中心核心)系统,最终实现“IBM小型机+AIX操作系统+DB2数据库+高端存储阵列”架构的全部替换。相比于传统的数据库,新研发的数据库强调数据强一致性、实时、高可用、高可靠、高并发、海量横向扩展等特点。特别是分布式事务的强一致性是分布式数据库设计的核心需求。

建设历程

中信银行在分布式数据库实践中,本着稳中求进、不断深入的思路,经历从简单到复杂、无钱到有钱、小额度到大额度、低并发到高并发、外围到核心的演进过程。典型里程碑包括:

1.冠字号系统:外围查询系统,于2015年9月投产;

2.门户网站系统:带有小额度的资金交易系统,于2016年5月投产;

3.金融同业平台:交易量小但是资金交易额度大的交易型系统,于2016年11月投产;

4.零售客户统一积分:交易量大,含隐性资金交易金额,于2017年6月投产;

5.卡中心核心业务迁移:交易量大,核心业务系统,于2019年10月投产;

6.总行电子渠道(对私)业务处理平台:交易量大,承载97%以上零售业务,于2019年11月投产;

7.总行核心业务迁移,计划于2020年上半年投产;

冠字号业务

中信银行纸币冠字号追踪管理系统原本基于IBM AIX6.1-64bit、Red Hat Enterprise Linux Server 5.5 和 DB2 9.7.0.5- 64bit开发并在各分行营业厅部署,考虑到分布式数据库在中信银行后续发展战略,2015年初总行营业厅冠字号系统被移植到用GoldenDB分布式数据库,移植工作和业务研发同步展开,移植过程中结合分布式数据库的特性对原数据库表进行优化调整,增加了分片键和适当索引调整,系统于2015年9月成功投产。
基于GoldenDB分布式数据库改造后的冠字号系统性能指标得到极大提升:
1.精确查询冠字号耗时由原系统15分钟缩减为1秒
2.模糊查询冠字号由原系统的15分钟缩减为5秒
3.冠字号+账号查询由原系统的15分钟缩减为1秒
4.根据账号进行精确查询由原系统的15分钟缩减为35秒  
冠字号系统共25张表,目前日交易量约300万笔,最大表约1亿条记录;系统由2个分片组成,各一主一备。
冠字号系统分布式迁移工作由分布式数据库团队负责实施,在实施过程中完善分布式数据库功能并积累迁移经验。

门户网站系统

门户网站系统的分布式改造涉及的模块主要有:产品关注管理、用户消息管理、短网址管理、缴费订单管理和交易流水管理。该系统是一个带有小额度的资金交易验证性系统,标志着GoldenDB在交易类业务验证中迈出的重要一步。
相比冠字号系统,门户网站系统涉及小额度资金交易验证,采用分布式数据库设计理念,通过多分片模式进行系统改造。门户网站共5张表,每日交易量约200笔;系统由2个分片组成,各一主一备。
门户网站的分布式数据库改造由门户业务项目组直接负责,分布式数据库由DBA深度介入模式展开。该系统于2016年初投产。
通过门户网站的分布式改造实践,分布式数据库设计理念、设计原则及设计要素逐渐得以业务开发部门贯彻。门户网站系统分布式数据库改造,充分体现了银行业应用架构改进的稳中求进的特点。

金融同业平台

金融同业合作平台是面向同业客户提供综合化服务、开放式互联网的系统,实现同业客户统一接入,可实现彼此资金、网点、产品、系统方面的优势互补、资源共享。金融同业合作平台自2016年11月26日投产以来,陆续提供了同业理财、外汇交易、代开保函、代开信用证、同业存放等功能,为全行金融同业业务的开展提供了有力支撑。从上线至2018年8月8日累计交易金额达20000亿。
金融同业平台共有65张表,每日交易量约2000笔;系统由2个分片组成,各一主一备。
在项目设计阶段,充分利用GoldenDB分布式数据库的特性,根据每张表不同数据量、不同使用方式有针对性地设计数据分布方案;在项目开发阶段,GoldenDB通过JDBC接口,无缝融入中信银行UCP框架,特别是强一致性的分布式事务支持,免去了各种异常场景下事务一致性的繁琐处理,极大地降低了金融同业合作平台项目开发复杂度。

零售客户统一积分

零售客户统一积分系统是全面覆盖借记卡、信用卡、消费金融、财富管理及私人银行、小企业金融等零售业务的客户忠诚度管理体系(奖励积分体系),是用户资料共享、数据实时流转,助力零售产品的交叉销售及营销推广的积分账务系统。零售客户统一积分系统自2017年8月18日投产以来,在提升中信银行零售客户忠诚度提供了有力的技术支撑。
1.性能提升:零售客户统一积分系统实现了交易级积分明细,因此数据存量和数据增量非常大。在系统测试验证中,GoldenDB6个分片支撑36亿的积分明细,积分查询峰值:4000TPS,单日请求300万笔;积分产生峰值:17万TPS,单日请求213万笔;积分兑换峰值:1827TPS,单日请求7万笔;
2.扩展灵活:随着中信银行信用卡“三年三倍增”的战略目标的实施,预期积分明细数据量会同步激增。GoldenDB使用基于哈希按照用户分片的策略,避免活跃新增用户和相对不活跃存量用户的不均,使得系统的整体负载更均衡。同时,一致性哈希也为今后的在线扩容提供了便利。
3.稳定性和可靠性:GoldenDB投产以后,至今运行稳定,未发生过数据丢失、运行抖动等异常。使用主备一致性监控,保证了各分片主备数据的一致性。在联机的积分消费和批量转联机的积分入账、批量的积分逾期处理多个典型场景下,都未出现数据不一致的异常情况。
4.运维组件易用性:平台内置对各组件运行的准实时监控模块,各组件运行异常会产生即时告,同时记录了一组有助于了解整个平台运行情况的统计信息;同时,长时间的运维类操作,如数据备份、在线重分布等,可通过可视化的界面查看任务的运行进度,降低运维难度。

卡中心核心业务系统

卡中心核心业务系统,从2017年10月开始立项,经过数十轮的跟账验证、试运行及切换演练后,新一代核心业务系统StarCard于2019年10月26日正式投产。新系统将信用卡系统的三大服务:授权服务,账户服务,数据服务核心业务系统从AS400下移到X86集群,12T的核心数据(8000w用户数据)从DB2迁移到GoldenDB。整个卡中心核心系统从原有的集中式架构迁移到具有前瞻性开放式架构中,打通了核心系统和大数据平台,实现面向决策的核心信用卡系统。
系统正式投产后,先后经历了双十一、双十二和年终决算的现网考验,至今运行稳定,无任何故障。其中双十一前的网联压测,数据库集群峰值吞吐量4500TPS,数据库集群平均查询量79000QPS,性能远超网联要求。在双十一期间交易量提升30%,其中系统日常平均交易量为授权1100TPS,双11时授权平均交易量1440TPS,账户平均270TPS,日终跑批数据库集群峰值吞吐量17000TPS,数据库集群峰值查询量224000QPS,跑批整体运行平稳。
系统设计为同城双活,设计容量为15000tps,可满足未来5-10年的业务发展,是原有业务系统容量的10倍。

总行核心业务系统

随着分布式数据库在中信银行的不断推进,中信银行于2017年启动总行核心X86分布式架构迁移预研,从2017年3月起,进行数据库选型论证,经过6个月的数据一致性、性能、高可用等专题测试后,2017年11月正式启动总行核心X86架构迁移。总行核心下移涉及1主体+11同步+15前置+4依赖项目,是一个子系统多,依赖项目广的超复杂项目。
下移总体目标:全面实现技术路线转型,达到国内领先水平;下移后核心系统的高安全性;坚持走自主可控的技术路线,可持续跟进和扩展;减小下移实施中,对业务的影响。下移设计容量目标:3亿客户、15亿账户、每日3亿交易量、可水平扩展,可在线扩展。联机处理设计性能:日常综合场景TPS20000,平均响应时间200ms以内;普通查询交易响应时间100ms以内;普通账务类交易响应时间300ms以内;可水平扩展,无软件瓶颈。日终批量处理设计性能:批处理运行期间,同时支持1000并发的在线联机交易,平均响应时间400ms以内。
系统由40个分片组成,每分片一主五备,生产机房一主一备,同城机房和异地机房各两备。当前处于攻坚冲刺阶段,预计2020年上半年投产。
最后修改时间:2020-05-07 11:38:51
文章转载自GoldenDB分布式数据库,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论