---
source_url: https://docs.dolphindb.cn/zh/db_distr_comp/db/three_centers_in_two_places.html
fetched_at: 2026-05-19T09:04:43Z
category: db_distr_comp
title: 两地三中心
sha1: b7fad500bad4d5370b1ff6d69e00d82dc29bd7cf
---

# 两地三中心

在生产环境中，业务连续性和数据安全性至关重要。为了应对各种灾难场景，需要建立完善的容灾体系：

- **容灾**：确保在灾害发生时系统能够持续运行，保障业务连续性
- **备份**：防范数据丢失，确保数据可恢复

两地三中心是目前广泛采用的容灾架构模式，它的核心思想是在两个不同地域部署三个数据中心，一般包括同城双中心和异地灾备中心，以抵御各种自然灾害、机房故障或网络中断等风险：

- **同城双中心**：是指在同一城市或邻近城市部署两个具备独立运行能力的数据中心。两个中心在业务处理能力上基本等效，之间通过高速链路实现数据的实时同步。在正常情况下，双中心可共同承担业务系统和管理系统的运行，实现负载分担与高可用；在突发灾难时，可实现快速切换，完成应急接管，确保业务连续性。
- **异地灾备中心**：在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地数据中心作为最后一道防线，用备份数据恢复双中心。

## 容灾架构

本章介绍 DolphinDB
支持的容灾架构，该架构巧妙融合了同城双中心与异地灾备的优势，旨在提供分层级的灾备保护，确保了在同城范围内的最高可用性以及在异地的数据灾备。部署模型如下图所示：

![](images/three_centers_in_two_places/1-1.png)

### 同城双中心

在同一城市范围内，部署两个独立的可用区（Available Zone）：AZ1 和
AZ2。这两个可用区在物理上相互独立，拥有各自独立的供电、网络、冷却等基础设施，以避免单点故障。同时，它们之间通过高速专线互联，确保了极低的网络延迟，为同城双活架构下数据的高效同步和毫秒级业务切换提供了坚实基础。

**AZ1 配置详情**：

- **数据节点**：部署 **2 个**数据节点。
- **计算节点**：部署 **1 个**计算节点。
- **数据副本策略**：在此可用区内，所有数据默认保存**双副本**，确保了 AZ1 内部的数据冗余和高可用性。

**AZ2 配置详情**：

- **数据节点**：部署 **3 个**数据节点。
- **计算节点**：部署 **1 个**计算节点。
- **数据副本策略**：在此可用区内，所有数据默认保存**三副本**，提供了更高的数据冗余级别和更强的容错能力。

### 异地灾备中心

异地中心通常部署在与同城双活区域相距甚远的地理位置，主要用于应对更为极端、城市级别的区域性灾难。DolphinDB
通过异步复制机制，将同城双活区域的数据安全、可靠地备份至异地中心。
这种异步复制模式可以在主备集群之间存在较高网络延迟的情况下有效运行，最大程度地减少对生产集群性能的影响，并保证即使同城双活区域完全失效，异地灾备中心也能确保数据的最终可恢复性，最大程度地降低数据丢失风险。关于异步复制的介绍及使用方法，请参考[集群间异步复制](../../tutorials/async_replication.html)。

### 数据一致性与高可用保障机制

在两地三中心分布式架构下，DolphinDB 运用多项机制，确保集群内数据的强一致性和高可用性：

- 两阶段提交协议 (Two-Phase Commit, 2PC)： DolphinDB 在处理集群分区数据的写入时，采用高效的 2PC
  协议。这确保了数据在 AZ1 和 AZ2 之间所有副本的强一致性。
- 多版本并发控制 (Multi-Version Concurrency Control, MVCC)： DolphinDB 通过 MVCC
  机制，在提供高并发读写能力的同时，进一步增强了数据的一致性和事务隔离性。MVCC
  允许读操作在不阻塞写操作的情况下进行，反之亦然。每个读操作都能获得一个时间点上的一致性数据快照，从而有效避免了读写冲突，显著提升了系统的并发吞吐量和整体性能。
- Raft 协议保障元数据一致性： 集群的元数据（如分区分布、副本状态等）由 DophinDB
  的控制节点负责存储和管理。为了保证元数据服务的高可用和强一致性，控制节点之间采用先进的 Raft 协议。Raft
  协议通过领导者选举、日志复制等机制，确保了所有控制节点上的元数据始终保持强一致，即使在部分控制节点故障时，也能自动选举新的领导者并保证元数据的快速恢复和稳定服务。

这些机制的协同工作，使得 AZ1 和 AZ2 均能独立承担业务，并在任何时刻确保两者之间的数据始终保持高度同步和一致。

### 故障恢复与业务连续性

**部分节点或副本故障处理**：

数据的多副本存储设计，使得剩余的在线副本能够接管服务，继续处理业务请求，确保业务不会中断。该过程对正在运行的业务完全透明。

**可用区整体故障切换：**

在极端且罕见的情况下，若某一可用区（以 AZ1 为例）的所有数据副本和相关节点均发生故障，导致该可用区发生整体性失效。此时，AZ2 将接管 AZ1
的所有业务流量和计算任务。由于 AZ2 也拥有 AZ1 的完整且一致的数据副本，业务能够实现快速、平滑地从 AZ1 切换至
AZ2，有效避免数据丢失和业务中断。

**故障节点在线恢复：**

当之前发生故障的节点（无论是单个节点还是整个可用区中的节点）得到修复并重新上线时，系统会通过在线恢复 (Online Recovery)
机制，将本地副本恢复至最新状态，从而继续提供服务。

### 性能

评估一个灾备系统可靠性的两个重要指标为恢复时间目标 （Recovery Time Objective，以下简称“RTO”）与恢复点目标（Recovery
Point Objective，以下简称“RPO”）：

- **RTO**是恢复时间目标，指灾难发生后，从系统宕机导致业务停顿开始，到系统恢复至可以支持业务部门运作，业务恢复运营之时，此两点之间的时间，RTO
  可简单地描述为企业能容忍的恢复时间。
- **RPO** 是恢复点目标，指灾难发生后，业务系统所能容忍的最大数据丢失量，它是衡量企业在发生灾难后会丢失多少生产数据的指标。

根据《中华人民共和国金融行业标准》关于分布式数据库技术金融应用规范灾难恢复要求的内容，分布式数据库灾难恢复能力应至少达到 4 级及以上能力要求，具体对应的
RTO、RPO、灾备部署等关键指标要求如下表所示：

| 容灾等级 | RTO（恢复时间目标） | RPO（恢复点目标） | 灾备部署 |
| --- | --- | --- | --- |
| 4级 | <= 30分钟 | 0 | 同城灾备或异地灾备 |
| 5级 | <= 15分钟 | 0 | 异地灾备，异地单副本 |
| 6级 | <= 1分钟 | 0 | 异地灾备，异地双副本 |

综合上述机制，DolphinDB 的容灾架构可以实现 6 级容灾，即 RTO<= 1分钟，RPO=0。

## 配置方法

要启用 DolphinDB 的两地三中心部署能力，需要对集群的关键配置文件进行相应修改：

- 无论您是搭建全新的 DolphinDB 集群，还是将现有集群升级并改造为两地三中心架构，只需修改配置文件并重启集群，即可实现该部署模式。
- 请确保 DolphinDB Server 版本在 2.00.16.1 及以上，低于此版本可能不支持两地三中心相关配置。

### 配置 cluster.nodes 文件

在集群节点管理文件 cluster.nodes 中，增加一列 “zone”，为每个数据节点和计算节点指定 zone 信息。

**配置格式：**

```dolphindb
localSite,mode,computeGroup,zone
10.0.0.80:8901:P1-agent,agent,,
10.0.0.80:8902:P1-datanode1,datanode,,zone1
10.0.0.80:8903:P1-datanode2,datanode,,zone1
10.0.0.81:8901:P2-agent,agent,,
10.0.0.81:8902:P2-datanode,datanode,,zone2
10.0.0.82:8901:P3-agent,agent,,
10.0.0.82:8902:P3-computenode,computenode,g1,
```

**配置说明：**

- **支持的节点类型**：支持数据节点和计算节点配置 zone。
- **默认 zone 处理**：如果数据节点不填写 zone 或配置中没有 zone 列，则默认分配到默认 zone 中。
- **完整性：**一旦为任意节点配置了 zone，则必须为所有数据节点和计算节点指定 zone。

### 配置 controller.cfg 文件

在控制节点配置文件 controller.cfg 中，为每个 zone 配置副本数。

**配置格式：**

```dolphindb
zone1.dfsReplicationFactor=2 // zone1的副本数为2
zone2.dfsReplicationFactor=1 // zone2的副本数为1
dfsReplicationFactor=2 // 默认zone的副本数为2
```

**配置说明：**

- **格式**：采用 `<zone名>.dfsReplicationFactor=<副本数>`
  的格式为每个 zone 指定副本数。
- **默认 zone 配置**：不带 <zone名> 前缀的 `dfsReplicationFactor`
  用于指定默认 zone 的副本数。
- **完整性**：必须为所有 zone 指定副本数。
- **副本数限制**：每个 zone 的副本数不得大于该 zone 包含的数据节点个数。
- **副本总数**：系统的总副本数即为所有 zone 的副本数之和。
- **配置变动影响**：如果配置发生变动，则不会影响已经分配的副本。这些变动只会影响后续新增的副本。

### 网络推荐

为了充分发挥两地三中心架构的性能优势和容灾能力，建议在网络层面进行优化：同城双中心之间（AZ1 <->
AZ2）务必使用专用高速网络链路（如万兆以太网或更高带宽的光纤连接），确保两可用区之间的网络延迟稳定控制在 3
毫秒以内。这是实现同城双活架构强一致性写入和快速故障切换的关键前提。

## 使用限制

为了保障两地三中心部署模式下集群的稳定运行和数据强一致性，以下操作在特定情况下会有所限制。

注：

以下“部分节点下线”是指集群中有节点下线，或可能导致集群总存活副本数小于设置的总副本数，但最多只有一个 zone
的存活副本数小于该 zone 设置的副本数。

| 操作 | 说明 |
| --- | --- |
| 写入已存在分区（`insert into`） | 支持在部分节点下线时执行 |
| `delete`、`update` | 支持在部分节点下线时执行 |
| 创建库表（`database`/`createPartitionedTable`） | 支持在部分节点下线时执行 |
| 删除库表（`dropDatabase`/`dropTable`） | 要求所有数据节点在线 |
| 重命名表（`renameTable`） | 要求所有数据节点在线 |
| 删除数据（`truncate`） | 要求所有副本均在线 |
| 删除分区（`dropPartition`） | - `forceDelete=false` 时，要求所有副本均在线 - `forceDelete=true` 时，允许在部分节点下线时执行 |
| `addRangePartitions` / `addValuePartitions` / `setRetentionPolicy` 等 | 支持在部分节点下线时执行 |
| 增加列（`addColumn`） | 支持在部分节点下线时执行 |
| 删除列/替换列（`dropColumn` / `replaceColumn`） | 要求所有副本均在线 |
| 添加注释（`setColumnComment`） | 支持在部分节点下线时执行 |

## 总结

通过开启 zone 配置并结合异步复制机制，可以有效实现金融级的容灾要求，满足两地三中心的部署架构，为业务连续性提供强有力的保障。
