1. 跨地域容灾架构总览
跨地域容灾的核心目标，是在主地域发生区域性故障时，仍能让数据库在可接受的数据损失与可接受的中断时长内恢复对外服务。要设计这样的架构，首先必须把两个最关键的指标说清楚：RPO（Recovery Point Objective，恢复点目标）和 RTO（Recovery Time Objective，恢复时间目标）。
RPO 描述的是"允许丢多少数据"，它用时间来度量数据的新旧程度。若 RPO=0，意味着故障切换后不允许丢失任何已提交事务；若 RPO=5 分钟，则允许最多丢失最近 5 分钟内产生的数据。RTO 描述的是"允许停多久"，即从故障发生到业务重新可用的最长时间。二者是容灾方案的两条硬约束：RPO 决定数据同步方式（同步还是异步），RTO 决定切换方式（自动还是手动、是否需要人工确认）。
关键理解：RPO 与 RTO 不是技术指标，而是业务指标。它们由业务方给出，架构师据此反推技术选型。把 RPO/RTO 当成"越接近 0 越好"是常见误区——RPO=0 通常意味着同步复制，会带来跨地域写延迟；RTO 越短，自动化切换的复杂度和误切换风险越高。合理的做法是按业务分级，不同业务用不同档位。
下面这张图把 RPO 与 RTO 在时间轴上的位置、以及多地域部署中主备数据流的关系放在一起表达，便于建立整体直觉。
多地域部署模式
从拓扑上看，跨地域部署常见三种模式，它们直接对应不同的 RPO/RTO 档位。
- 主备（Active-Standby）：主地域承担全部读写，备地域通过流复制持续接收 WAL，平时只读或待命。故障时把备库提升为主库。这是 PostgreSQL 最成熟、最常用的跨地域模式，RPO 取决于同步或异步复制，RTO 取决于切换自动化程度。
- 双活（Active-Active）：两个地域同时承担读写。PostgreSQL 原生不提供跨地域多主写入，通常需要借助逻辑复制、分片或外部中间件实现，冲突处理复杂，跨地域写延迟敏感。适合对 RTO 要求极高、且能接受最终一致或分片写入的业务。
- 级联 / 多级备（Cascading）：主库只向一个就近备库同步，再由该备库向远端地域级联复制。可降低主库跨地域同步开销，但远端 RPO 会叠加一跳延迟，故障切换链路也更长。
PostgreSQL 容灾技术选型对比
PostgreSQL 生态中可用于跨地域容灾的技术主要有物理流复制、逻辑复制、基于 WAL 归档的 PITR，以及外部高可用编排工具。它们的定位不同，不能互相替代。
| 技术 | 复制粒度 | 典型 RPO | 典型 RTO | 适用场景 |
|---|---|---|---|---|
| 物理流复制（同步） | 整实例 WAL | 0 | 秒级～分钟级 | 核心交易，不能丢数据 |
| 物理流复制（异步） | 整实例 WAL | 秒级～分钟级 | 秒级～分钟级 | 跨地域常规容灾 |
| 逻辑复制 | 表 / 行级 | 秒级～分钟级 | 分钟级 | 部分表容灾、异构同步 |
| WAL 归档 + PITR | 整实例，按时间点 | 取决于归档频率 | 分钟级～小时级 | 误删恢复、合规留存 |
| 外部 HA 编排（如 Patroni） | 配合流复制 | 继承复制模式 | 秒级～分钟级 | 自动故障切换 |
选型思路：先用 RPO 筛掉不满足数据丢失要求的技术，再用 RTO 决定是否需要自动切换编排，最后用成本与运维复杂度做取舍。跨地域场景下，同步复制会显著增加写延迟，通常只在同城或低延迟链路使用；跨地域更常见的是异步流复制 + 自动切换编排，把 RPO 控制在秒级、RTO 控制在分钟级。
一个可参考的示例参数
假设某业务要求 RPO ≤ 10 秒、RTO ≤ 5 分钟，主地域在上海、备地域在北京，两地网络往返延迟约 25ms。若采用同步复制，每次提交都要等待北京确认，写延迟至少增加 25ms，对高频写入不友好；因此选择异步流复制，并配合自动故障切换工具。此时 RPO 由 WAL 传输延迟决定，正常网络下通常在 1 秒以内，满足 10 秒要求；RTO 由故障检测、备库提升、流量切换三部分组成，通过健康检查间隔 3 秒、提升耗时约 20 秒、DNS/代理切换约 30 秒，合计可控制在 1 分钟以内，满足 5 分钟要求。
-- 主库 postgresql.conf 关键参数（异步流复制示例）
wal_level = replica
max_wal_senders = 10
wal_keep_size = 2GB
synchronous_commit = off -- 异步，优先降低写延迟
archive_mode = on
archive_command = 'cp %p /archive/%f'
-- 备库 recovery 配置（PostgreSQL 12+）
primary_conninfo = 'host=sh-primary port=5432 user=repl password=***'
restore_command = 'cp /archive/%f %p'
需要强调的是，以上参数与耗时均为教学示例，实际部署必须结合链路质量、数据量和业务写入特征实测验证。RPO 与 RTO 的达成不是配置一次就一劳永逸，而应通过定期演练来确认：演练时记录最后一次成功同步的时间点、切换开始与结束时间，与目标值比对，才能判断容灾架构是否真正达标。