两地三中心：企业灾备避坑指南

作者：孙浩然

两地三中心，听着很贵，但真正贵的是你没做

去年年底，一个做证券的朋友半夜给我打电话。他们交易系统所在的机房，空调管路爆了。不是火灾，不是断电，就是空调水管裂了。听起来像小事对吧？结果整个机房温度在二十分钟内飙到四十五度，核心交换机先扛不住，然后数据库主节点开始疯狂报错。他们倒是有备份，但备份在同一个机房。备份文件和主数据一起“泡”在热浪里。

后来复盘，他说了一句话我记到现在：“我们做了备份，但没做容灾。这是两码事。”

这话其实点到了今天要聊的主题——两地三中心。

先说清楚，两地三中心到底是个啥

别被这个词唬住。拆开看就三件事：

“两地”，指的是地理上分开的两个城市，至少隔个几十上百公里。为什么要分开？因为同一个城市可能一起遭殃——地震、洪水、大面积停电、光缆被挖断，这些灾难不跟你讲道理，一个城市里放几个机房，可能一锅端。

“三中心”，指的是三个数据中心，分别是：生产中心、同城灾备中心、异地灾备中心。

生产中心就是平时跑业务的那个。同城灾备中心一般在同一个城市或者临近城市，走光纤直连，数据同步延迟能做到毫秒级。它的核心作用是——当生产中心挂了，业务能快速切过去，通常要求几分钟甚至几十秒内完成。异地灾备中心就远了，可能隔几百上千公里，数据异步复制过去，延迟大一些，但它防的是区域性大灾难。同城那两个都没了，异地那个还在。

说白了，同城灾备保的是“快”，异地灾备保的是“活”。

为什么光有备份不够

我遇到过不少运维同行，觉得“我每天都备份，怕什么”。说实话，这个问题我一开始也没想通，后来踩了个坑才发现区别大了。

备份解决的是数据逻辑错误——比如误删表、数据被篡改、中了勒索病毒。你可以从备份里恢复。但备份有个前提：你得有环境去恢复。如果机房整个没了，你备份文件再完整，没有服务器、没有网络、没有存储，恢复个啥？

容灾解决的是物理灾难——机房断电、火灾、水淹、地震。它要求的是另有一套完整的环境，能随时接管业务。

打个比方：备份是你把家里的贵重物品拍了照片存云端，东西丢了你知道长什么样，但得重新买。容灾是你另外买了一套一模一样的房子，家具电器全配好，这边塌了那边直接住。

两者不是替代关系，是互补的。

一个真实的场景

前年有个做在线教育的客户找我聊。他们当时用户量涨得很快，CTO开始担心业务连续性。我问他一个问题：“如果你的主库挂了，你多长时间能恢复？”

他想了想说：“大概两三个小时吧，从备份恢复。”

我说：“那你算过两三个小时停课，损失多少吗？”

他沉默了。

后来他们做了同城双活加异地灾备的架构。今年三月份，他们主机房所在区域真的出了电力故障，整个园区断电。同城灾备中心在九十秒内接管了全部流量。用户端几乎没有感知，就是APP闪了一下。

他后来跟我说，那一刻觉得钱花得值。

话说回来，不是所有业务都需要两地三中心。你得先搞清楚自己的RTO和RPO——也就是“能容忍多长时间恢复”和“能容忍丢多少数据”。这两个指标决定了你该花多少钱、建什么样的架构。

核心交易系统，RTO可能是秒级，RPO接近零，那必须上同城双活甚至多活。内部OA系统，RTO半天一天都行，那异地备份加冷备就够了。别一刀切。

两个避坑提醒

第一个坑：同城灾备不等于同城双活。

很多人以为在同一个城市建两个机房就是双活了。差得远。双活意味着两个中心同时承载业务流量，任何一个挂了，另一个无缝接管，用户无感知。而灾备中心平时可能是待命状态，切换需要时间，切换过程中业务会中断。这两者的成本和技术难度差了一个数量级。别被供应商的方案书忽悠了，看清楚写的是“双活”还是“主备”。

第二个坑：异地灾备的带宽和延迟，一定要实际测。

理论上说异步复制对带宽要求不高，但实际跑起来，如果数据写入量很大，带宽不够会导致复制队列积压。积压到一定程度，异地那份数据就落后太多了，真切换过去可能丢几个小时的数据。我之前见过一个案例，异地复制延迟常年在一小时以上，根本达不到RPO要求，但没人注意过。后来真出事的时候才发现，异地那份数据基本没用。

建议定期做切换演练。不演练的容灾方案，约等于没有。

最后说几句实在的

两地三中心不是万能药，它解决的是物理层面的业务连续性问题。对于大多数企业来说，先把自己的RPO和RTO搞清楚，再根据业务重要性分级，把钱花在刀刃上。

如果预算有限，至少做到：核心数据异地备份，关键业务同城有个能快速拉起的环境。这比什么灾备都不做要强一万倍。

我自己的经验是，容灾这件事，只有在真出事的时候你才知道它值不值。但真出事的时候再想建，已经来不及了。