金融业分布式数据库:SequoiaDB、GoldenDB、OceanBase等原理、POC性能对比及选择是怎样的？

感谢大家对GoldenDB的关注，关于GoldenDB的信息，大家可以看一下这一篇文章。
看的出来大家都GoldenDB存在一些误会，比如说中间件+mysql的误会，借这里我澄清一下
借用oceanBase白皮书中的一个说法，中间件+开源数据库存在4个不足

那么全局一致性事务是我们的最主要的竞争力，不然中信银行也不会采用，GoldenDB采用一阶段提交+事务补偿的方式，对业务完全透明，还能避免而极端提交prepare阶段和commit阶段短暂的不一致，不需要业务写异常回滚。
复杂的跨库查询，全局索引，和全局一致的DDL都是我们最基本的特性。
因此说我们是中间件我们真的有点冤。

GoldenDB在中信银行信用卡核心应用实践

摘要：中信银行卡中心新核心系统于2019年10月27号正式开业。采用中信银行与中兴通讯联合研发的分布式数据库GoldenDB来承载核心业务系统，该数据库是国内第一家在大型股份制银行信用卡核心系统成功落地的国产分布式数据库。

随着信息技术的发展，金融行业已经进入4.0时代，金融服务已经突破传统的服务边界，变得无处不在，这对银行的战略布局、营销模式以及IT系统提出更高的要求。

中信银行信用卡中心于2017年开始启动分布式新核心系统建设，目标是扩展业务范畴、完善经营模式、提升活跃客户量、提升业务交易量。要求核心系统具备架构的前瞻性，构建资源可扩展的开放平台，能够快速响应业务大规模增长，实现面向决策的核心信用卡系统。

中信银行卡中心新核心系统于2019年10月27号正式开业。采用中信银行与中兴通讯联合研发的分布式数据库GoldenDB来承载核心业务系统，该数据库是国内第一家在大型股份制银行信用卡核心系统成功落地的国产分布式数据库。
GoldenDB分布式数据库

GoldenDB主要由4个功能模块节点构成：

计算节点： 与业务通过标准JDBC连接，主要用于解析业务SQL请求，分布式优化，分布式路由以及分布式事务控制。

数据节点： 由数据库实例构成，用于承载业务数据，支持横向水平扩展，多数据副本保证数据安全可靠。

全局事务管理节点： 负责分布式事务生命周期的管理，与计算节点一起进行分布式事务控制。

管理节点： 对集群进行管理，负责系统集群的高可用，管理系统元数据。同时对备份恢复、主备切换、监控分析都提供了可视化的操作界面。

GoldenDB产品架构图

中信银行核心数据库应用实践

中信银行信用卡核心系统，主要包括授权、账务、数据服务等三块业务系统。每种业务场景不一样，性能要求也不一样，分布式优化方案也各有侧重点。另外，如何保证在尽可能短的时间内，顺利正确地完成数据迁移也是非常重要的。

核心分布式数据库部署

核心系统的三个业务内部的故障不能相互感染。因此，在设计业务连接实例时，把业务连接的计算节点进行物理隔离，杜绝业务故障的传染性。且业务系统要求的隔离级别和运行模式也不一样，在集群配置上也能做到统一管理，灵活多变，方便后期运维管理。

在底层数据节点，配置的X86服务器性能很高，从成本和可用性上考虑，一个数据服务器中部署了两个数据库实例，不同服务器之间做交叉主备，同时主备机磁盘也相互独立。保障单机内主备机磁盘IO隔离，单机异常也不会影响系统可用性。

中信银行核心业务系统架构图

核心业务分布式设计应用实践

卡中心核心业务中最重要的业务是授权联机交易业务，对时延非常敏感，以快捷支付业务为例，单笔业务30多条SQL语句，时延必须小于40ms。因此，替换分布式数据库后，必须消除分布式带来入侵性并提供稳定的高性能服务。

中信银行信用卡新核心分布式设计

首先，在数据模型方面，所有业务表按照客户号进行拆分。大表先分表再分区，减少单分片上的压力。常用的小表加载到Redis上，减少网络消耗的同时，提升数据查询性能。

其次，梳理交易场景，对业务进行分布式优化。优化后的交易，GoldenDB仅作简单路由，业务语句直接下推到DB层执行，减少分布式事务开销，提升业务响应时间。

最后，增加业务映射表，减少业务层的复杂性。在核心系统内添加客户号映射表，业务中只需增加获取客户号的流程，即可方便的拿到客户号，这样后续业务中的事务控制就可直接下推到数据库底层DB节点完成，业务层不必关注事务控制逻辑。

最终性能压测达到1.8W TPS达到上线标准，稳定通过网联4500TPS压测，以及双11和双12实际考验。

核心批处理业务分布式应用实践

批处理业务的特点就是在一定时间窗口内，集中处理一批数据文件。这个期间内业务会调起大量的并发，在短时间内完成跑批作业，对于分布式系统来说，如何做好跑批作业的分布式优化也是难点。

如按照原有逻辑批量处理业务，业务统一按照分布式业务场景处理，部分业务场景未优化，并行度不高，我们对业务进行了分布式和非分布式业务场景的识别，优化逻辑处理流程。梳理出可分布式改造的业务场景，数据文件先导入到的分片表中，然后对一个分片内的数据进行批量操作，所有分片并行处理，提升并行度，缩短了处理时间。

业务划分后，从系统稳定性角度出发，再梳理批处理业务逻辑，按照业务场景并行处理批处理作业。提升业务的并发度，降低系统资源压力。

最终核心日终批处理性能提升1倍，处理时长优化到1.5小时以内。

核心数据迁移应用实践

数据迁移作为卡中心核心系统下移关键一步，整个迁移要在很短的窗口期内完成，业务会以数十万的并发来加快迁移过程，大量迁移数据会使得网络长期维持在高负荷的状态。要求数据库能够在高并发、重负载的业务场景下，提供稳定可靠的数据服务。

中信银行信用卡新核心数据迁移流程

数据迁移的主要流程： 外围系统数据文件通过文件传输平台落到共享存储上，旧核心的DB2数据文件通过FTP下载到Hadoop集群，通过调用MCO转码工具转码后，生成标准的数据文件落到HDFS上。迁移工程运行在容器云中，通过生成insert语句和调用迁移工具两种方式将两部分数据迁移到GoldenDB内：

在整个迁移过程中，采用了如下方案确保数据迁移的效率：

1、优化业务逻辑。在高并发场景下，合理使用索引，调整业务逻辑顺序，最大程度减少锁冲突问题。

2、优化数据库参数。使得数据库在迁移阶段具备一定的容错能力，如适当调大锁等待时间，将切换阈值调高，容忍系统心跳延迟等。

整个核心业务投产数据迁移期间，最大活跃连接数达到24万，网络流量峰值达到900MB/s。在这种极端的业务场景下，历经了数十次的演练，顺利完成了核心业务投产数据迁移工作。

自2014年以来，中信银行与中兴通讯共同研发分布式数据库GoldenDB，稳中求进，不断深入。在冠字号、门户网站、金融同业平台、统一零售积分系统、电商管家、开放银行、用户权益系统以及信用卡中心核心系统陆续成功投产。
中信银行信用卡中心分布式核心系统StarCard于2019年10月27日正式开业，支撑1亿用户，日均交易9000万笔，顺利通过双十一的业务峰值考验，数据库性能表现平稳。经过5年的不断打磨，GoldenDB经历了严苛的商用考验，已经具备全面替换银行交易类业务数据库的能力。、中兴通讯领导参加了启动仪式。

（原文载于《金融电子化》2020年1月刊，作者：中信银行 张兴强 陈建峰 中兴通讯 付裕 戴扶）1