两地三中心

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

AZ1 配置详情：

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

AZ2 配置详情：

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

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

在两地三中心分布式架构下，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、灾备部署等关键指标要求如下表所示：

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

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

配置格式：

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 中，为每个 zone 配置副本数。

配置格式：

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 毫秒以内。这是实现同城双活架构强一致性写入和快速故障切换的关键前提。