毫秒级时延，银行核心系统如何保证交易安全？

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

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

那么，银行核心系统是否可以采用互联网应用部署模式来实施？比如，按三地五中心五副本部署银行核心系统的分布式数据库，并基于Paxos/Raft协议确保三地五中心间的数据复制强一致性。然而，三地五中心部署方案要求至少两个城市间距离较近，网络时延10ms，城市1和城市2各承担50%的银行核心业务，负载均衡。使用该方案部署银行核心系统有着三方面的缺点：远距离部署导致数据库读写性能下降明显；标准Paxos/Raft对等的容灾切换策略不符合银行核心系统要求；采用三地五中心部署银行核心系统成本更高。

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

具体表现在以下方面：

同时，为保障银行核心系统的业务连续性服务需求，《商业银行业务连续性监管指引》要求：商业银行应当建立灾备中心等备用信息技术资源和备用信息系统运行场所资源，并满足银监会关于数据中心相关监管要求。

目前，主流的灾备中心布局模式有同城灾备中心、异地灾备中心以及两地三中心等三种模式。

（1）同城灾备中心。灾备中心与生产中心处于同一城市，一般距离在几十公里内，可采用同步复制技术实现数据的实时复制。具有投资低，灾难恢复速度快，极高的数据保障等能力，主要防范火灾、电力/通信系统中断等事件，但无法应对同时覆置生产及同城灾备中心的区域性灾难风险。

（2）异地灾备中心。灾备中心与生产中心在不同的域市，一般距离在数百公里以上，通常采用异步数据复制技本。投资成本较高，灾难恢复速度与数据保障能力略低，但可应对区域性的灾难风险。

（3）两地三中心。是同城灾备中心加异地灾备中心的结合，同时具备前两者的优点，可以最大程度地保护数据安全，保持系统的连续运行。两地三中心是目前我国大中型银行普遍采用的灾备布局模式。

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