一、容灾概述：到底什么是容灾？
大家好，我是老张。今天咱们聊聊容灾。
说实话，我见过太多团队把「容灾」和「备份」混为一谈。有一次在客户现场，对方CTO拍着胸脯说「我们做了容灾」，结果我一看，就是个每天凌晨跑一次的数据库dump脚本。嗯，这哪是容灾，这连备份都算不上完整。
那到底什么是容灾？
容灾，就是当灾难发生时，你的系统还能继续提供服务。
注意关键词——「继续提供服务」。不是「数据还在」，不是「能恢复」，而是「还在跑」。这区别大了去了。
1.1 为什么需要容灾？
你想想看，一个电商系统，双十一当天机房断电了。数据没丢，但恢复用了4小时。这4小时损失多少？我经历过一次，那真是电话被打爆，老板站在身后盯着你操作，后背全是汗。
容灾要解决的核心问题就三个：
- 数据不丢：RPO（恢复点目标），说白了就是你能容忍丢多少数据
- 服务不停：RTO（恢复时间目标），就是你能容忍停多久
- 体验不降：切换过程对用户透明，别让用户看到502
核心观点：容灾不是「出了事再想办法」，而是「出了事系统自己搞定」。我个人的习惯是，把容灾当成系统的一个基础能力来设计，而不是事后补救措施。
1.2 容灾的等级标准：国际标准SHARE 78
说到容灾等级，绕不开SHARE 78标准。这是IBM在1990年代提出的，把容灾分成了7个等级。虽然年代久远，但至今仍是业界参考基准。
| 等级 | 名称 | 核心特征 | RTO | RPO |
|---|---|---|---|---|
| Tier 0 | 无容灾 | 没有任何备份，数据裸奔 | N/A | N/A |
| Tier 1 | 备份/恢复 | 磁带备份，异地存放 | 24h+ | 24h |
| Tier 2 | 备份+热备 | 备份+备用硬件 | 12-24h | 24h |
| Tier 3 | 电子链接 | 在线数据传输，有延迟 | 4-12h | 4-12h |
| Tier 4 | 批量/实时复制 | 异步复制，数据接近实时 | 1-4h | 分钟级 |
| Tier 5 | 双站点+数据一致性 | 同步复制，保证数据一致 | 分钟级 | 秒级 |
| Tier 6 | 零数据丢失 | 同步复制+自动切换 | 秒级 | 零丢失 |
我个人的经验是，大部分互联网公司做到Tier 4到Tier 5就够用了。Tier 6的成本太高，除非是金融、支付这类场景，否则没必要硬上。
避坑指南：我曾经见过一个团队，为了追求「零数据丢失」上了全同步复制，结果业务高峰期延迟飙升，反而影响了线上服务。容灾不是越高级越好，适合业务场景的才是最好的。
1.3 容灾与备份的区别
这个问题我每次培训都要讲。很多人觉得「我每天备份了，就是容灾了」。错，大错特错。
咱们用个比喻：
- 备份：就像你给重要文件拍了照片，存在保险柜里。文件丢了，你可以翻照片重新打印一份。但这个过程需要时间。
- 容灾：就像你有个双胞胎兄弟，你这边出事了，他立刻顶上继续干活。用户根本不知道换人了。
区别在哪？
| 维度 | 备份 | 容灾 |
|---|---|---|
| 目标 | 数据可恢复 | 服务可持续 |
| 恢复对象 | 数据文件 | 整个系统 |
| 恢复时间 | 小时到天 | 分钟到秒 |
| 数据丢失 | 允许丢失（取决于备份频率） | 尽量零丢失 |
| 成本 | 相对低 | 相对高 |
说白了，备份是容灾的基础，但不是容灾的全部。我建议每个团队都先做好备份，再考虑容灾。别一上来就搞双活，结果连个完整的备份都没有，那才是本末倒置。
注意：备份≠容灾。备份是「出了事我能恢复」，容灾是「出了事我不需要恢复」。这两个概念千万别搞混。我曾经在面试中问过这个问题，10个人里有6个答不上来。
1.4 容灾的核心知识体系
下面这张图是我自己画的，把容灾的核心知识点串了起来。你看一眼就能明白整个体系长什么样。
1.5 我的个人建议
做容灾，别想着一口吃成胖子。我见过太多团队，上来就搞「两地三中心」，结果运维能力跟不上，反而把系统搞得更复杂。
我的建议是：
- 先做好备份：这是底线。每天全量备份+增量备份，异地存放。
- 再搞同城容灾：同机房或同城双活，成本可控，效果明显。
- 最后考虑异地：如果业务真的需要，再上异地容灾。
小技巧：我个人习惯用「容灾矩阵」来评估每个系统的容灾需求。把系统按重要性分S/A/B/C四级，S级必须Tier 5以上，C级Tier 2就够了。这样资源分配更合理，不会出现「所有系统都上最高标准」的浪费情况。
好了，这一章就到这里。容灾不是个技术问题，更是个意识和规划问题。下一章咱们聊聊具体的容灾架构模式，包括主备、双活、多活这些到底怎么选。
公众号:蓝海资料掘金营，微信deep3321