1. 术语介绍

说明：
在下文中，机房、数据中心、IDC 是同义词
在下文中，数据库不仅指关系型数据库，还可能是 Redis、MongoDB 等数据库

术语	解释
冷备	定期将主数据中心的数据库文件备份到其它数据中心。冷备不提供实时服务。当丢失数据时，可以通过冷备恢复数据，以保证数据安全
热备	通过数据库主从复制或 binlog 订阅等技术，对主数据中心进行实时备份。热备提供实时服务，当主数据中心不可用时，热备可以自动接管业务，保证业务不间断运行，用户端对主备切换无感知
同城机房	同城的数据中心之间物理距离比较近，并且使用专线连接，虽然跨数据中心的访问延迟比单个数据中心内部要大，但是可接受
异地机房	异地的数据中心之间物理距离较远，网速延迟是不可忽视的因素。比如北京到上海的距离是 1300 公里，即便架设专线，光纤以光速传输，一个来回也要 10 ms。线路之间还有路由器、交换机等设备，实际延迟可达 30ms ～ 100ms，如果网络抖动，延迟可能达到 1s

2. 故障分类

类别	出现原因	概率	影响面
主机故障	主机硬件故障、网络故障、负载过高等	大	小
机房故障	机房网络故障、电力故障、制冷系统故障、自然灾害等。比如塘沽爆炸事故	小	大
地域故障	战争、强自然灾害等。比如河南水灾	极小	极大

3. 同城多活

说明：

应用在操作数据库时，需要读写分离。每个机房的应用读本机房的从库，写主机房的主库
为避免跨机房写数据库，可以在接入层将写请求只路由到主机房
同城多（双）活可以解决主机故障、机房故障，但是无法抵抗地域故障。

4. 两地三中心

两地是指 2 个城市，三中心是指 3 个数据中心，其中 2 个数据中心在一个城市，并且同时提供服务，第 3 个机房部署在异地，只做灾备，防止数据丢失。

说明：

可以抵抗地域故障，但是通过冷备重建服务需要时间，服务将间断，用户端有感知

5. 伪异地多活

架构与同城多活类似。

说明：

可以抵御地域故障。但是无法就近访问，异地写数据库延迟高

6. 异地双活

6.1. 实施方案 1

两个机房的存储必须可写，而且两个机房还要互相同步数据，只有这样才能支持切换机房，持续提供服务。

如果两个机房同时操作同一条数据，那么将发生冲突。因此该方案要求数据库或数据同步中间件具备合并数据，解决冲突的能力。比如 MySQL 提供双主架构，但 MongoDB、Redis 未提供该能力。解决冲突时，假如以时间为标尺，以后到达为准，那么要求两个机房的时钟严格同步。

6.2. 实施方案 2

从源头避免冲突，在接入层将请求区分开。比如按照业务类型、根据用户 ID 计算哈希值、按照地址位置等方式将请求分流到不同的机房。

7. 异地多活

在异地双活的基础上，部署多个机房：

随着机房越来越多，当一个机房写入数据后，需要同步的机房也越来越多。为降低复杂度，将网状架构升级为星型：

一个机房写入数据只需要同步到中心机房，再由中心机房同步到其它机房。当中心机房发生故障时，将任意机房提升为中心机房，继续按照之前的架构提供服务。

8. 单元化

单元化架构也叫 Set 化架构。容灾以业务为中心。它将应用、数据、基础组件按照统一的维度切分成多个单元，每个单元处理一部分闭环流量。比如在一个机房内完成同一用户的所有相关请求，而不出现跨机房访问的情况。业务以单元作为部署单位，通过单元互备方式实现同城容灾或者异地容灾。

9. 数据库架构

9.1. 主从架构

9.2. MGR 架构

MySQL Group Replication（简称 MGR）是 MySQL 5.7.17 版本引入的服务端插件，用于创建高可用、可扩展、容错的复制拓扑结构。它基于原生的主从复制，将各节点归到一个组中，通过组内节点的通信协商（组通信协议基于 Paxos 算法），实现数据的强一致性、故障探测、冲突检测、节点加组、节点离组等功能。

上面 3 个节点互相通信，每当事件发生时，向其它节点传播该事件，然后协商，如果大多数节点都同意这次事件，那么该事件将通过，否则该事件将失败或回滚。这些节点可以是单主模式（single-primary），也可以是多主模式（multi-primary）。单主模式只有一个主节点接受写操作，主节点故障时自动选举主节点。多主模型下，所有节点都可以接受写操作。关于 MGR 的更多细节，请参阅 https://blog.csdn.net/solihawk/article/details/118183944。