当你的唯一数据中心宕机时会发生什么？

谈到数据库架构，很多决策都是出了故障之后才补上的。可到了那时，往往已经太晚。这篇文章会通过两个参考现实情况构建的场景，讨论如何为 PostgreSQL 系统设计高可用与灾难恢复方案：从小企业使用的单数据中心，到横跨三座城市的分布式架构，逐一看看哪些设计有效、哪些地方存在缺口，以及这些差异为什么重要。过程中，我们也会介绍 RPO、RTO、故障切换，以及地震、网络中断等物理风险。无论你是从零搭建系统的工程师，还是负责长期业务韧性的决策者，都值得在危机到来前，把这些问题想清楚。

图片

为什么数据库架构很重要

在企业里，系统架构经常被忽略，却又关系着关键业务能否持续运行。遗憾的是，不少组织仍然抱着一种简单的想法：“搭台服务器，装好软件，问题就解决了。”现实远比这复杂。假设你正在为依靠生命维持设备的病人设计医疗系统，电源接好了，设备也正常运行。但如果突然停电呢？生命可能因此受到威胁，所以备用供电不可缺少。数据库也是一样。数据库崩溃或无法访问，损失的不只是数据，还可能包括时间、声誉，以及客户的信任。

像工程师一样思考

工程师的工作，不只是“让它能用”，还要让系统能够长期运行，并在故障中恢复。因此，每个项目开始时，都应该先问自己：

• 需要多少台服务器？
• 服务器应该部署在哪里？
• 全部放在同一个地方，够不够？
• 供电或网络中断之后怎么办？
• 业务能接受多少数据丢失，以及多长时间的停机？

没有回答这些问题，就直接决定基础设施，可能会在日后留下代价高昂、难以补救的隐患。

核心概念：RPO 与 RTO

RPO，恢复点目标：

它定义的是，业务最多可以接受多长时间范围内的数据丢失。比如：“最多可以丢失最近五秒的数据。”这项要求会直接影响：

• 选择同步复制还是异步复制。
• 备份频率。
• 硬件容量。
• 整体成本。

RPO 必须由技术团队与业务部门共同确定，并明确记录下来。

RTO，恢复时间目标：

它定义的是，故障发生后，系统应在多长时间内恢复服务。例如：“停机不能超过十分钟。”这个指标会影响：