关于大型数据库双活难点问题研究

上官斌

摘要：为保障7×24持续运行，越来越多的大型政企单位的核心业务，大都逐步开始推进系统双活建设。其中最重要，也是最难的，是如何实现大型数据库双活。包括仲裁一致性、性能同步、异常切换决策都是确保双活建设成功，达到建设目标需要重点研究取舍的关键性难点。通过在实际生产中主持千万用户级电信系统双活建设实践，成功实现了连续3年业务零中断，演练RPO≈0，RTO<10分钟。现总结了其中数据库双活建设的一些实践性经验，供从业者参考。

关键词：数据库;双活;一致性;同步;切换

中图分类号：TP311        文献标识码：A

文章编号：1009-3044（2022）08-0023-03

1 双活系统建设难点

包括金融、电信、政府等大型政企单位的核心业务用户级通常达到数百万级乃至千万级、亿级，业务数据量巨大，大型关系型数据库技术得到越来越广泛的应用。

过去我们关注数据库的数据量大小，如今我们更加关注的，其实是从技术架构和用户影响的角度去思考。从技术架构角度，大型数据库系统一般采用双机或多机集群复杂技术体系;从用户影响角度，大型数据库系统一般承载数百万乃至千万用户级以上用户数据，一旦数据库故障或宕机，将可能直接影响千万级用户的业务体验，甚至业务中断。

为保障7×24不断网，不断电持续运行，核心业务大都逐步开始进行系统双活，两地三中心，甚至多地多中心的系统建设。在双活系统建设中，基本都会遵循网络双活、应用双活、数据双活三个层次的架构设计原则。其中最重要，也是最难的，是如何实现大型数据库双活。尤其是如何解决大型数据库集群之间的仲裁一致性、如何保障数据库同步性能、节点异常情况下的切换决策问题。更是一个需要平衡的难点。

2 数据库双活实现

为了提升实时性業务服务性能，业务模块可引入Dcache等分布式缓存数据库，提升读写、亿级用户业务快速处理能力。而由于业务订购关系数据主要存储在Oracle/MySQL等数据库，而业务鉴权和处理主要依赖Dcache。因此根据异地业务的双活容灾，双站之间的Dcache也需要保持数据的一致性。Dcache 与数据库之间需要维护数据的一致性。

两个中心（IDC1和IDC2）会融合成一套异地双活部署的网关，业务通过GSLB全局负载均衡，因此需在两个中心部署业务检测和切换系统。每个站点部署一套监控服务器监控所有接口机，处理机与数据库的工作状态。

当数据库发生异常的时候，由监控服务器通知所有的接口机和处理机进行数据库切换和业务恢复。当监控服务器监控到某个模块的业务成功率低，可以根据预定策略对该模块进行重启或者下线处理。

3 数据库双写

IDC1和IDC2机房的基于Oracle RAC和Dcache分布式高性能方案保证数据的高可靠性，移植性，同时兼顾高并发，高访问等特点。与此同时业务需要通过配置数据双向写入IDC1和IDC2的数据库中，保证两个站点的数据一致。为保障双活数据库性能，直连链路时延需要控制在5ms之内，考虑到传输设备和传输距离的影响，同时兼顾异址容灾安全，一般要求两个双活IDC的距离保持在30km到100km之间，实际工程中，通常通过大带宽（GB以上）裸光纤链路直连两个IDC。

IDC1机房作为主数据库;IDC2机房作为备份数据库。

通过域名方式访问业务系统配置台，对配置数据进行配置操作。不论接入的是运行在IDC1或者IDC2机房的业务系统配置台。配置的数据都会双向同时写入IDC1机房和IDC2机房的数据库，实现了两个机房的数据一致。

新增配置双写流程：

（1）正常流程

① 业务系统配置台新增数据;

② 在IDC1数据库中写入新数据;

③ IDC1数据库返回成功响应

④ 在IDC2数据库中写入新数据;

⑤ IDC2数据库返回成功响应

（2）异常流程1

① 业务系统配置台新增数据;

② 在IDC1数据库中写入新数据;

③ IDC1数据库返回成功响应;

④ 新增数据成功;

⑤ 在IDC2数据库中写入新数据;

⑥ IDC2数据库返回失败响应;

⑦ 告警并生成SQL文件，需要管理员检查并IDC2数据库，运行正常后手工执行SQL文件。

（3）异常流程2

① 业务系统配置台新增数据;

② 在IDC1数据库中写入新数据;

③ IDC1数据库返回失败响应;

④ 新增数据失败;

⑤ 不在IDC2数据库中写入新数据。

业务双写即业务系统对数据的增删改操作，同时写入IDC1和IDC2的数据库。

4 数据一致性难点破解

4.1数据一致性等级

数据的一致性有几个等级，弱一致性 < 最终一致性 < 强一致性。强一致性是关系数据库的基本特征，而NoSQL产品一般都只实现到最终一致性，否则也没有余地去实现其他优势特性。最终一致性的意思是，数据的多个复本间有可能不是实时一致的，但是经过有限的时间或步骤，最终是能够达到一致的。

在分布式系统中常见的复本策略有这么几种：主备策略、主从策略、Quorum策略。相对于传统的主备、主从策略而言，Quorum方式更加灵活，可以对多节点读写兼顾平衡控制。

Quorum N/R/W中，N是一份数据总共存入几个节点（在Dcache中，特定的Key存入哪些节点是相对固定的，后面会详细讲）;R是读取数据时，在N个节点中有多少读取成功则认为读取成功;W是写数据时，在N个节点中有多少写成功则认为写入成功。F5CDA0EE-B226-4D1F-9AD6-B0F99FF02FD8

一般来说，在R+W>N时，认为是数据一致性程度较高的，不会出现写了新数据却读到旧数据的情况。比如最典型的场景是N/R/W=3/2/2，有两个重要意义：

①数据成功写在一部分节点上后，后面读数据时不可能只选择跟之前完全不同的另一部分节点，至少会有R+W-N个节点是重合的，这就保证了读取到的R个数据中，至少有一个是之前刚写过的新数据;

②因为在3/2/2模型中，R

4.2内存数据库一致性

在Dcache中，一致性强度是可根据Quorum策略灵活配置的：

当N=W=R时，是实现了强一致性，但是可用性方面很差，单点故障即影响业务应用的访问。

最常用的还是R+W>N的模式，典型配置是N/R/W=3/2/2，兼顾可用性和数据一致性，虽然多个复本间的数据不可能每个瞬时都一致，但是最终多个复本间是一致的，而且每次业务应用对数据的读取都建立在R个复本的比较之上，而这个模式中R个复本里至少会有一個最新的，最终返回给业务应用的也是正确的数据。可以认为，在同时最多只有单点故障发生的情况下，其一致性效果是逼近强一致性的。

Key/Value是一种新型的数据存取方式，确实能解决一部分问题，但不能解决所有问题，要避免出现对Dcache盲目使用的情况，有些流程中确实不适合使用Key/Value方式，这些问题如果规划阶段没有发现的话，在性能测试阶段可能会暴露出来。

上线以前务必要按实际的业务逻辑和实际的数据规模，在实际的硬件条件下进行性能测试。强烈建议在现网上线前预留充足的时间，直接在现网设备上进行性能测试，及时识别和排除潜在的各种干扰。

而且要覆盖尽可能全面的业务逻辑，如果流程A和流程B存在某种关系，流程间的协作也都要覆盖到。数据规模方面，测试时一定要达到实际的数据规模和离散程度，因为Dcache是有缓冲的，数据量很少时，所有请求在内存中即可命中，数据规模大时，可能会访问到磁盘，所以性能表现跟数据规模是有关系的。

为了适应Dcache，原来业务处理机有关白名单鉴权的所有访问内存库的业务流程都需要移植和改造。同时为了提升访问的性能，业务处理机需要维护多个Dcache客户端线程进行读/写。

另外为了满足容灾的性能，需要提供Dcache的同步工具，是实现业务双写。以及冷备站点的Oracle数据同步到Dcache。

4.3数据库集群一致性

为了数据的安全，基于Oracle RAC方案的高可靠性，因此数据库采用Oracle RAC，同时由业务双写保证两个站点的数据一致。

通信层管理节点之间的通信。它的职责是配置，互联群集中节点信息，在群集管理器中使用由心跳机制产生的信息，由通信层负责传输，确保信息的正确到达。还有一些群集监视进程不断验证系统的不同领域运行状况。例如，心跳监测不断验证的心跳机制的运作是否良好。

每个站点部署一套监控服务器监控所有接口机，处理机与数据库的工作状态。当数据库发生异常的时候，由监控服务器通知所有的接口机和处理机进行数据库切换和业务恢复。

5 数据库切换

两个IDC会融合成一套异地部署的双活业务系统，平时IDC1机房的业务系统和IDC2机房的业务系统都和部署在IDC1机房的主站数据库（包括Oracle和Dcache）连接，所以需在IDC1和IDC2机房同时部署监控服务器，监测数据库状态。监控服务器中部署检测和切换系统，其部署方式如图所示。

监控服务器同时连接业务系统的接口机和处理机。业务系统的接口机和处理机部署驻留程序，通过驻留程序检测数据库访问成功率。

接口机、处理机数据库访问成功率：

（1）业务系统各个接口机、处理机节点定期上报数据库访问成功率数据给监控服务器的检测系统，上报间隔要求可配置，默认为30S。

（2）监控服务器的切换系统根据检测结果和判定规则，向告警网元发送故障告警。

（3）切换服务器决定是否切换。

检测项结果定义：

节点数据库访问成功率：各个处理机节点的数据库访问成功率（X个节点）。

探测系统最终上报的关于数据库探测结果内容如下：

[检测结果项 来源 说明 备注 节点数据库访问成功率 各处理机节点 各个处理机节点的数据库访问成功率 根据实际情况，每次包含N个节点数据 ]

切换类型逻辑判定分自动切换和人工参与的半自动切换两类。

（1）半自动切换场景

建议数据库的各类异常，都要求人工参与判定，因为各类判定参数，只能做切换依据。

当然用户也可以设置为自动切换。

（2）自动切换条件设置

数据库自动切换判定规则：

监控检测结果展示到可视化状态管理界面，用户可以查看。

如果选择的人工切换，则显示一键切换按钮。否则显示自动切换，用户不可操作，只能查看状态和日志。

当满足数据库切换条件时，监控服务器通知各个接口机及处理机节点进行数据库访问切换。

当主用数据库恢复之后，需要将数据库访问进行回切。

数据库切换流程为：

l 检查数据库恢复状态

l 执行数据同步

l 通知各个接口机及处理机节点进行数据库访问切换

6 结束语

双活系统架构设计应遵循必要的基本原则。应充分考虑网络双活、应用双活、数据双活三个层次，才能充分规避由于单出口网络故障、应用服务器故障、数据库错误造成的业务影响。其中难点和重点在数据库双活的设计和实现，在建成后的应急演练中，应充分模拟数据库各种接口增删改查操作，各层级故障现象的发生，以及数据库整体切换演练。不断优化工程中可能考虑不周的情况进行优化，最终实现系统长时间可靠的0中断运行， RPO≈0，RTO≈0。以上是笔者在实践基础上的一些总结，对电信级两地三中心系统建设中特别是大型数据库双活架构设计及实施工作的有效开展，具有积极的借鉴意义。

参考文献：

[1] 梁凝，单晓强，孙叠.数据库同步技术的研究[J].工业控制计算机，2017，30（7）：118-119，122.

[2] Futurewei Technologies Inc. Patent Issued for Decentralized Distributed Database Consistency[J].Information Technology Newsweekly，（USPTO 10，503，725）

[3] 朱红.基于MySQL集群实现的高性能数据库架构设计[D].上海：上海交通大学，2014.

【通联编辑：王力】F5CDA0EE-B226-4D1F-9AD6-B0F99FF02FD8