文 / 贵州银行信息科技部总经理 韩凌中

贵州银行信息科技部 韩海松 宋勇 何威

2019年，中国人民银行在发布的《金融科技（FinTech）发展规划（2019—2021年）》首次提出“加强分布式数据库研发应用”规划；2022年，中国人民银行发布的《金融科技发展规划（2022—2025年）》对“关键软硬件技术金融应用研究攻关持续深入”提出了进一步发展规划。

(资料图片)

近年来，商业银行经营环境正在发生剧烈变化，在新技术浪潮推动下，银行信息系统需要面对海量交易、“秒杀”、7×24小时不间断服务的挑战，对传统IT架构造成了较大的冲击。在监管规划指导和业务发展双重压力驱动下，国有大型银行、股份制银行、城商行等纷纷开始了新基础架构的探索与实践。其中，由集中式向分布式数据库转型成为金融科技创新的重大课题。

贵州银行顺应行业趋势，研究和借鉴行业经验，经过近5年不断实践与总结，主要交易类和支撑类系统完成了分布式数据库改造，满足了本行新业务场景的需求。系统投产后，在客户识别、流程简化、场景编排、智能风控、精细化管理、业务创新等多维度对业务转型进行支持、赋能和引领，探索出一条“有别于他行，立足于自己特色”的分布式数据库转型之路，在银行同业产生了积极影响。

贵州银行 信息科技部总经理 韩凌中

分布式数据库选型和特点

与业内大多数城商行一样，贵州银行上一代信息系统采用典型“IOE”架构模式设计，随着数字化时代的到来，传统架构问题日益凸显。一是传统架构各模块间耦合度高、架构封闭，软件开发和产品服务交付周期长，无法快速响应市场需求；二是高并发下处理能力瓶颈，资源弹性扩展能力差，系统运维难度日益增加；三是系统关键基础软硬件长期被国外厂商垄断，IT成本居高不下，尤其是当国际安全环境变化时，系统存在潜在供应链风险。

结合近年来银行业实践经验，分布式架构转型的关键在于引入先进的分布式数据库产品，满足系统高性能、高并发、高可用、低时延、强一致性的分布式事务处理需求，并符合以下技术选型要求。一是产品质量与性能。主要关注分布式事务一致性保障、高可用、高并发、横向扩展能力等关键技术指标。二是产品生态。关注金融核心系统行业案例、应用开发商数量、服务器厂商适配广度。三是运维能力。运维工具的成熟度。四是SQL兼容能力。兼容SQL92、99、2003等相关标准。五是兼顾产品价格与售后支持能力。

根据上述建设目标，贵州银行建设了分布式数据库系统，具备技术标准高、关键业务多、创新替代全三大特点。

一是技术标准高。分布式数据库既满足联机交易高效实时处理能力要求，又满足夜间海量数据批处理时高并发、高性能处理要求，同时还满足秒杀、团购等海量在线客户流量的“小额高频交易”需求。处理存/贷/汇等关键业务数据，分布式数据库在对应用程序不侵入的前提下，能够保证系统全局分布式事务实时强一致性。

二是关键业务多。贵州银行在国内城商行中率先完成核心、渠道、信贷等主要交易类系统全面分布式数据库改造，在研发和运维实践中，总结出一套分布式数据库关键业务系统的开发指导和集成实施规范。

三是创新替代全。在实施分布式数据库改造过程中，全面满足了替代工作的要求。改造系统不仅在应用层、数据库层实现了创新替代。在PASS层，通过结合云平台提供的丰富PAAS层资源，替代了传统的Tuxedo、Weblogic、Vmware等传统基础软件；在IAAS层，通过PCServer服务器,替代了传统小型机；通过高性能Nvme磁盘，替代了传统高端存储。

分布式数据库建设方案

结合贵州银行实际需求，从业务特点、交易量、应用级别、高可用要求、宕机影响等关键指标，分布式数据库集群采用“3+1”整体规划方案，即：3套交易类业务集群+1套支撑类业务集群。这样设计，既可以有效规避新架构的未知风险隐患，在重要变更时优先在非核心业务集群上实施，以充分评估技术方案风险，同时非核心业务的运行不会对核心业务造成影响。

1.功能架构

如图1所示，分布式数据库采用无共享的分布式架构设计，由计算节点集群、存储节点集群、管理节点和全局事务管理器四个部分组成。

图1 分布式数据库架构图

（1）计算节点集群层

由无状态的计算节点组成，计算节点从驱动层或者管理节点接收用户的操作，进行逻辑优化和物理优化，生成满足分布式事务一致性的分布式查询计划。计算节点在执行分布式查询计划时，通过持续地访问存储节点，从而完成用户的最终操作请求。

（2）存储节点集群

存储节点集群是应用数据的最终存储组件。所有存储节点组成一个或多个数据库集群。数据库集群由一个或多个安全组组成，集群中每个表的数据按照特定策略进行横向分片后存放到对应的安全组中，分片策略一般有复制、哈希、范围和列表策略。随着安全组数量的增加，每个安全组承载的数据量和读写负载会相应地减少，从而实现读能力和写能力的水平扩展。

（3）管理节点

负责集群管理流程，不涉及业务的访问，无负载压力，通过多数派（Paxos）协议保证该节点的高可靠性。管理流程主要包括元数据、计算节点集群、存储节点集群、任务，以及运维管理。

（4）全局事务管理器

全局事务管理器实现全局分布式事务的全生命周期管理，是分布式事务控制中心，提供申请、释放、查询全局事务的能力。

2.部署架构

在分布式数据库部署层，各集群设计如下。

“两地三中心”规划：以贵安数据中心和金阳数据中心为同城主备中心，遵义数据中心为数据级灾备中心，副本数量设计为3:2:1。

核心集群规划：主要包含核心、CBF两套系统。

全渠道集群规划：主要包含全渠道前端、全渠道后端、ECIF、全媒体通知等业务系统。

信贷集群规划：包含信贷（个贷、公贷、小微）、开放银行、非零内评等管理类系统。

支撑类集群规划：包含统一认证、影像平台、反欺诈等支撑类系统。

生产与同城应用规划：生产与同城中心应用实现对等部署，对外提供双活服务能力。数据库生产2副本加同城1副本写成功后，才给应用反馈成功，保证同城双中心数据RPO为0。

数据级灾备中心机房不部署应用，仅保留业务数据。分布式数据库通过异步复制技术将业务数据实时备份至异地机房。

分布式数据库交易类集群物理部署图如图2所示。

图2 交易类集群物理部署图

3.分布式数据库持续优化过程

当前，基于分布式数据库的关键系统研发在业内可参考案例不多。在系统研发过程中，各种技术问题不断涌现，其中若干问题揭示出分布式架构底层存在个别重大风险隐患。为彻底解决隐患并尽可能发现和解决未知风险，贵州银行引入混沌工程理论和方法，邀请业内技术专家共同精心设计了服务器强制断电、关键进程被恶意强杀、核心设备网络风暴、核心网络交换机瘫痪、各模块服务器恶意断网、管理节点脑裂、恶意删库、删表等34个破坏性场景，搭建专项环境，开展了严格的测试验证工作。对于需要人工干预的个别场景，完善应急预案，有效化解了破坏性场景下系统运行风险。在破坏性测试工作基础上，贵州银行设计“延迟落库”方案：在分布式数据库集群各分片增加一个备副本。日常运行时，通过技术参数将备副本日志数据延迟应用。当故障发生时，即刻将延时落库副本由“备”改为“主”，并快速应用本地日志到数据库集群可用最后时刻，如此可防范因系统故障造成的数据丢失风险。

4.性能指标

投产后，各集群I/0性能较传统“机械硬盘+千兆网”架构有近30倍的提升，单条SQL的插入/更新平均耗时小于1毫秒，各关键技术指标均满足中国人民银行《关于分布式数据库技术金融应用3项金融行业标准》要求。截至目前，核心系统交易平均耗时50毫秒；渠道系统及信贷系统交易平均耗时200毫秒。各系统整体运行平稳，性能指标优异。

分布式数据库应用实践

投产后，应用系统凭借分布式数据库高并发、横向扩展的优势，较好地支撑了“i茅台”“行庆十周年秒杀”“双十一”等海量在线客户流量场景的需求，推动了行内金融产品与互联网的深度融合，系统处理能力得到了大幅提升，基础架构实现了灵活扩展，提升了贵州银行的竞争力。

系统适配分布式数据库改造过程中，在代码设计、集成实施、投产割接，以及后期系统运维阶段，贵州银行解决了大量行业技术难题。

1.代码改造规范性

业务从集中式向分布式架构转型时面临着开发模式调整，在解决复杂业务逻辑和处理性能上遇到了较多问题。针对复杂业务逻辑，通过SQL改造、分拆SQL处理过程和多并发改造，合理利用分布式架构提升了整体查询性能，充分发挥了集群并行处理优势，并将实践经验整理成了相关开发规范和指导手册。

2.分布式系统双活方案的技术制约与突破

通常分布式系统的双活架构需要三个对等机房才可实施，以解决数据一致性和服务可用性矛盾。贵州银行通过分布式数据库分组管理、高低水位等创新技术实现了“两地三中心”架构下的双活部署。在正常情况下，业务运行在高水位，将数据同步到同城机房才提交事务；当同城机房或者同城光纤出现故障，将数据复制到本地机房其他副本才提交事务，同时产生告警；当本地机房出现故障，进行跨数据中心自动调度，将应用请求平滑切换到同城机房，保障业务连续性。该技术方案既可提高机房设备利用率，又能降低日常容灾演练复杂度。

3.全局分布式事务处理逻辑的并网验证

贵州银行对多套关键应用系统的体系架构、实现逻辑和系统间接口进行了重构。尤其在分布式事务设计时，分布式数据库通过二阶段事务处理实现分布式事务的原子性，通过全局事务管理器（GTM）实现分布式事务隔离性。在事务处理异常时，整个事务回滚过程对应用层完全透明。未提交事务通过单节点数据库自身进行回滚，已提交的子事务通过基于日志自动补偿机制进行全局回滚，结合传统冲正重发处理机制，严格保证各极端灾难场景下全局事务的原子性、一致性、隔离性和持久性。为充分验证系统分布式事务逻辑正确性，系统投产前，将生产数据迁移到新分布式系统进行了多轮并网验证测试，经多次严格数据比对落标，充分验证了分布式数据库分布式事务处理逻辑的正确性。

4.分布式系统运维难题及解决措施

分布式系统架构复杂，集群规模庞大。以分布式数据库为例，PC Server散落在三个数据中心，数据库内部涉及计算节点、数据节点、全局事务管理器等多种部件，且内部交互较为复杂，给生产运维带来巨大挑战。为了应对分布式系统的运维挑战，贵州银行建设了统一化、可视化集中管理平台，对三个数据中心的设备进行整体监控、配置和运维操作，较大程度地降低了线上运维难度。

总结与展望

贵州银行分布式数据库自2020年底投产以来，先后多次受到金融生态实验室、信通院等国内IT权威机构邀请，分享先行先试经验。不少业内专家指出，贵州银行分布式数据库应用实践是银行业在金融科技领域非常重要的、可借鉴、能推广的标杆，为银行业分布式数据库关键技术应用、集成交付、投产演练、人才培养等领域做出了先进表率。

银行业竞争正在演变为金融科技的竞争，技术创新是金融科技发展的基石。贵州银行正着力提升创新能力，全面贯彻落实《金融科技发展规划（2022—2025年）》和银保监会《关于银行业保险业数字化转型的指导意见》要求，在后续多芯（海光/鲲鹏/龙芯/飞腾）、多操作系统（麒麟/统信）、多IT基础设施（存储/服务器/网络/安全/终端设备）的“3+1+N”全栈替代实践中，将不断拓宽应用场景，积极响应国家战略，持续为业内分享先行先试经验，勇当金融科技排头兵。