银行核心系统分布式数据库技术架构探讨

中兴通讯股份有限公司 左奇

银行核心系统作为银行交易和账户处理中心，是银行信息系统的最关键环节，是各大银行最繁忙、交易量最大的应用系统。当前银行核心系统数据库解决方案大多采用大型主机加高端大型数据库的方式提供，但随着金融行业数字化转型以及移动互联网业务的迅猛发展，银行核心数据库需要具备支持海量数据场景下的高性能、高可扩展、高可用等关键特征，而传统数据库的单机性能有限、扩展性差、软硬件价格昂贵等问题也逐渐暴露出来，促使银行核心数据库由集中式向分布式架构转型。

近几年，分布式数据库技术取得突破性进展，不仅实现了海量数据场景下的高性能、可扩展性需求，还满足了交易型数据库必须支持的分布式事务、数据强一致性、高可用等特性，如Google Spanner分布式数据库实现全球跨域的数据复制强一致性和高可用。另外，x86架构的PC服务器借助各种硬件加速技术（如SSD、RDMA、GPU等），弥补了只有大型主机才具有的高性能、高可靠性短板。这些技术发展都为分布式数据库替换金融核心数据库提供了强有力的支撑。

的需求重点是有差异的，银行核心应用对分布式数据库的核心需求是：满足海量数据场景下的高性能、高可扩展、高可用性等要求，采取“两地三中心”部署方案侧重解决容灾备份的需要，近距离部署方案可大幅降低网络对分布式数据库的性能影响。这两个应用场景间的详细差异见表1。

“三地五中心”部署方案面对银行核心系统需求“水土不服”

基于表1的对比，银行核心系统是否可以采用互联网应用部署模式来实施？比如，按“三地五中心”五副本部署银行核心系统的分布式数据库，并基于Paxos/Raft协议确保“三地五中心”间的数据复制强一致性，如图1所示。

“三地五中心”部署方案要求至少两个城市间距离较近，网络时延10ms，城市1和城市2各承担50%的银行核心业务，负载均衡。使用该方案部署银行核心系统的缺点如下：

一是远距离部署导致数据库读写性能下降明显。银行现有不少核心业务依赖于核心数据的集中读写操作，用户账号、交易数据库的跨域部署会增加读写时延及降低吞吐量。一方面，“三地五中心”方案因距离远而造成更大的网络时延（10ms，城市间距离增大，时延会更大）；另一方面，使用Paxos/Raft协议会比主从复制造成更大的响应时延，网络时延和协议时延叠加后，数据库响应时延会进一步放大，严重拖累核心应用的读写性能。以银行转账交易服务为例，因为金融安全、监管、风控等功能的需要，单次转账交易就需要有数十条以上的数据库读写操作，时延累加将严重影响转账交易的可用性。此外，时延增加还会导致数据复制吞吐量性能下降明显。例如基于Paxos协议实现的Mysql Group Replication数据复制方案，当网络延时从0.1ms上升到

银行核心应用场景分布式数据库与互联网应用场景分布式数据库需求差异的比较

在一个“Best-Effort”的互联网环境下，为达到更好的用户体验，大型互联网应用需采用分布式架构，就近部署在用户附近的数据中心，再通过数据中心间高质量的DCI网络实现互联互通以及容灾备份服务，而跨区域多写场景下的数据一致性、分区容错性则由分布式数据库来保证。一些互联网公司结合上述互联网应用需跨区域全球服务、负载均衡的需求特点，设计出多种分布式数据库，如Google Spanner、Amazon DynamoDB等。Google的广告业务就是基于Spanner实现跨区域全球服务。

但是，互联网应用与银行核心应用对分布式数据库

2019 . 05 中国金融电脑

81

INDUSTRY OBSERVATION

业界观察

表1 互联网应用与银行核心应用对分布式数据库的需求侧重点

分布式数据库互联网应用场景需求银行核心应用场景需求部署场景数据全球跨域/跨市多数据中心分布式部署，如“三数据同城灾备/“两地三中心”部署地五中心”部署方案特点：距离近(同城几十公里内）、时延低（低特点：距离远（至少几百公里）、时延大（大于于2ms）、成本低5ms）、成本高多区域写：数据库跨区域部署，就近提供数据库读写单区域写：为保证数据库一致性及性能，仅服务单区域写入，多区域可读跨分片的分布式事务需求低，且可通过应用/中间件数据库跨分片支持分布式事务实现跨分片分布式事务异地容灾、负载均衡。数据复制强一致前提下的自动同城容灾、热备。数据复制强一致前提下的灾难恢复，异地容灾，可用性级别谨慎切换，RPO=0、RTO<30s时延容忍度较高一致性优先，确保副本数过半数据处理逻辑简单时延容忍度低，毫秒级容忍度可用性优先，确保数据库可用数据处理逻辑复杂数据库读写分布式事务数据容灾时延容忍度异常处理数据处理难度标准Paxos/Raft仅依据最新副本的多数派的公平投票原则实现自动选主，缺乏整体感知和选举控制策略等方面的考虑。

三是采用“三地五中心”部署银行核心系统成本更高。相比于“两地三中心”部署方案，“三地五中心”需要更多的IT资源，资源成本大大增加；同时，“三地五中心”间需跨城市的高速宽带专线，比“两地三中心”方案有更昂贵的网络运维成本。

同城灾备/“两地三中心”部署分布式数据库更适合银行核心系统要求

综上所述，银行核心应用与互联网

图1 基于Paxos/Raft协议的“三地五中心”部署方案应用的分布式数据库核心需求是有差异

的，银行核心应用对分布式数据库采取“两地三中心”部署方案侧重是解决容灾备份的需要，近距离部署方案可大幅降低网络、复制协议对分布式数据库的性能影响，而采用“三地五中心”方案部署银行核心系统，不仅成本更高，还将导致核心业务性能下降等问题。因此，基于同城灾备/“两地三中心”部署分布式数据库更适合银行核心系统的要求。

20ms时，吞吐量下降到原来的1/3。

二是标准Paxos/Raft对等的容灾切换策略不符合银行核心系统要求。银行各数据中心资源是不对等的，主数据中心拥有最好的IT资源及运维保障力量，而异地灾备中心可能仅具备数据备份却不具备业务接管的能力，而且还受业务可用性、性能、数据一致性以及各类监管和运维需求的，跨数据中心切换非常谨慎，而

82

FINANCIAL COMPUTER OF CHINA