4月28日，由北京金融科技产业联盟、移动支付网联合主办的线上直播栏目《金融科技大讲堂》第二十一期开播。在本期直播中，华为技术有限公司华为云数据库首席产品经理贾新华向大家分享了数据库高可用技术的适用场景和演进路径，以及各技术方案在金融案例中的应用实践情况。

在金融领域中，业务的持续可用极为重要，数据持续可用是业务持续可用的保障。统计显示，数据中断对金融业务的影响远高于其他业务。金融应用的数据库高可用方案选择是保证业务持续可用的关键。

数据库高可用方案可分为几个发展阶段：

最初是以IBM为服务商的软硬一体方案。

1980年后，软件、硬件分层协同方案逐步兴起，Oracle、Informix、EMC、华为等成为数据库、存储典型代表，也就产生了目前银行应用最为主流的数据库解决方案。

2010年后，随着云和互联网的快速发展，以AWS、阿里云、华为云等为典型代表的软硬一体方案和以GaussDB、TiDB、OceanBase、GoldenDB等为典型代表的软件方案也涌现了出来。

传统数据库高可用方案及应用情况

IBM作为软件硬件一体化的厂商，通过磁盘复制技术提供高可用能力，这种方案的优点是总体RPO时间较短，缺点是单个RTO时间较长，灾备数据库不能提供服务，资源利用率较低。在国内银行与IBM联合创新中，同城数据中心的RTO可缩小至2分钟以内，灾备资源可以提供只读服务，资源利用实现得到了提升，但数据库和业务需协同切换，二者并非对称运行。

Oracle作为数据库软件厂商，从数据库层面提供全栈高可用方案。基于此方案，同城数据中心的灾备资源可以提供服务，最大化利用资源。这种方案的优点是ADG只同步日志，网络资源利用率高，灾备资源可提供只读服务，RTO时间短，但其和IBM的方案均属非对称运行方案，数据库仍需和业务协同切换。随着用户对Oracle方案进行创新，OGG实现“双活”，即两个数据中心均可用于生产，经单元化处理后可提供读写服务，但缺点是RPO不等于0，数据库无法保证一致性，只有在上层业务保证的前提下，方能确保数据库不冲突。

存储设备厂商可提供数据中心内、数据中心间全套数据高可用方案。这一方案存储有专用网络协议，效率较高，但数据和日志均会传输，传输量大，缺点是RTO时间较长，灾备资源不可提供服务，而且数据库和业务仍需协同切换，二者非对称运行。

为了适应同城场景，存储厂商亦对方案做出改进，“Oracle+华为”即是部署极简的对等方案。此方案运用了HyperMetro技术，可使两个数据中心的存储镜像成为同一个LUN，Oracle当成一个存储来用，RTO实现秒级，RPO等于0，其优点是业务全对等部署，RAC可同时提供服务，部署运维简单。

新兴互联网场景下数据库高可用方案

MySQL是历史最为悠久的数据库之一，多运用于互联网网站等场景。MySQL只提供基础复制能力，高可用方案由多个生态伙伴负责，其在银行业有半同步、异步等运用场景，仲裁逻辑和切换逻辑比较复杂。目前，MySQL存在两大弱势，一是基于binlog的复制效率比REDO效率略低，二是主备切换后或导致日志分叉。

Google Spanner可谓分布式数据库的“鼻祖”，全球很多开源分布式数据库均有借鉴Google理念。Google Spanner在全球只有一套数据库，服务于多个业务领域，这便需要通过Paxos组的部署、Zone的部署解决访问问题，通过Paxos解决数据一致性、日志分叉、仲裁（数据自仲裁）等问题。

AWS Aurora作为云厂商代表之一，其方案是通过软硬全栈提供数据库高可用能力。云厂商在租户面提供Region和AZ两级概念，AZ为独立可用区，Region为距离较远的城市；

Region内采用Quorum协议，即R是读节点数，W是写节点数，T是总节点数，协议规则是R+W>T，W>V/2。

在“同城”内提供3AZ高可用，每个AZ内2个副本共计6个副本，T=6，R=3，W=4，故障2个副本或1个AZ不影响服务，故障3个副本或者1个AZ不影响读服务。

Global Database的特性是提供跨Region高可用能力，出于运维和部署归一性，架构是对称的，软件实现RPO<1s, RTO<1min。

思考与建议

选择最佳的数据库高可用方案，需首先了解当前的技术趋势。随着互联网业务的兴起，数据库软件厂商话语权扩大，高可用已实现向软件方向转移。与此同时，云模式提供了软件全栈机会，软硬件结合提供更好的技术方案是云的必然趋势。此外，高可用还需考虑到一些约束或基本前提，比如硬件是不可靠的，软件一定是有BUG的，高可用一定要和成本做平衡等。

结合上述，贾新华认为：业务负载的重要性不同，在高可用方面的投资不同，高可用方案需要越发丰富，以满足不同侧重的需求。对于异地数据中心而言，城市级故障概率极小，异地容灾硬件资源远小于生成硬件资源，故采用独立数据库集群更加灵活。若考虑到城市间的距离较远，网络质量和带宽存在不确定性，数据库层复制对网络要求相对较低，那么采用数据库层高可用方案更加合适。

至于同城数据中心，因数据中心级故障有一定概率，故一般建议同城容灾中心和生成中心的硬件资源一致，确保发生切换时服务不下降。单数据库集群跨多AZ和每个AZ都是一个独立的数据库集群，两种方案会在较长一段时间内同时存在，前者在互联网类中广泛应用，后者在关键核心业务中应用较多。

更多精彩内容欢迎扫码进入课程回看：

本文来源：分布式数据库专委会

设计制作：会员服务部

投稿邮箱：News@bfia.org.cn