1. 容灾概述：调度系统为什么需要容灾、RPO与RTO核心指标、容灾等级标准

1.1 调度系统为什么需要容灾？

说实话，我刚入行那会儿，也觉得调度系统就是个“任务分发器”。挂了重启不就完了？直到有一次，我在一家金融公司做运维。

那是个周五下午。核心调度集群的一个节点因为内存泄漏挂了。按说还有备用节点，但备用节点的状态同步有个 bug——它没把正在执行的任务上下文拉过来。结果呢？2000 多笔交易对账任务全部失败，数据对不齐。财务部门加班到凌晨三点，手动补数据。

从那以后，我彻底明白了：调度系统不是“可有可无”的中间件，它是整个数据 pipeline 的“心脏”。心脏停跳几秒，全身都会出问题。

调度系统容灾的必要性，说白了就三点：

• 任务不能丢：调度系统里跑的任务，往往是批处理、ETL、数据同步。丢一个任务，可能意味着报表出不来、数据不一致、甚至业务中断。
• 状态不能乱：调度系统维护着大量任务状态——等待、运行中、成功、失败、重试。一旦状态错乱，你根本不知道哪些任务该继续、哪些该重跑。
• 依赖不能断：任务之间有上下游依赖。A 跑完 B 才能跑。调度挂了，依赖链断了，整个工作流就瘫痪了。

1.2 RPO 与 RTO：容灾的两个“命门”

做容灾方案，你绕不开两个指标：RPO 和 RTO。我习惯把它们叫做“容灾的命门”。

• RPO（Recovery Point Objective，恢复点目标）：你能容忍丢多少数据？说白了，就是最后一次备份到灾难发生之间的时间差。RPO=1小时，意味着最多丢1小时的数据。
• RTO（Recovery Time Objective，恢复时间目标）：你能容忍系统停多久？从灾难发生到系统恢复可用，这个时间就是 RTO。RTO=30分钟，意味着必须在半小时内让系统跑起来。

这两个指标是“对头”。RPO 越小，备份频率越高，成本越大。RTO 越小，恢复手段越复杂，投入越高。你想想看，RPO=0 意味着实时同步，RTO=0 意味着双活——那得花多少钱？

指标	定义	典型值（调度系统）	代价
RPO	数据丢失容忍度	1分钟 ~ 1小时	备份频率越高，存储和带宽成本越大
RTO	系统恢复容忍度	5分钟 ~ 4小时	恢复手段越快，架构复杂度越高

1.3 容灾等级标准：你的系统在第几层？

容灾等级，业内有个通用的分类标准。我习惯把它分成 6 个层级，从低到高：

1. L0：无容灾 —— 挂了就挂了，手动重启。小公司、测试环境常见。
2. L1：冷备 —— 有备份，但需要手动恢复。比如每天备份一次数据库，挂了之后手动恢复。
3. L2：温备 —— 有备用节点，但需要手动切换。比如主从架构，主挂了手动切到从。
4. L3：自动切换 —— 系统自动检测故障并切换。比如 Keepalived + VIP，主挂了自动漂移。
5. L4：主备实时同步 —— 主备之间数据实时同步，切换后数据几乎不丢。比如 MySQL 半同步复制。
6. L5：双活/多活 —— 多个节点同时提供服务，任何一个挂了都不影响。比如两地三中心、多集群调度。

嗯，这里要注意：等级越高，不等于越适合你。我见过不少团队，一上来就搞双活，结果运维成本翻了三倍，业务收益却没多少。容灾等级的选择，得跟业务价值匹配。

1.4 调度系统容灾的核心逻辑

调度系统的容灾，跟普通应用不太一样。普通应用容灾，主要保数据。调度系统容灾，除了保数据，还得保状态、保依赖、保任务连续性。

我画了一张图，帮你理清调度系统容灾的核心逻辑：

你看，调度系统的容灾流程，其实就三步：

• 检测：通过心跳、健康检查发现节点或服务异常。
• 决策：评估当前状态，检查依赖链是否完整，决定是否切换。
• 恢复：恢复任务状态，校验数据一致性，让系统重新跑起来。

这三步里，决策是最难的。我遇到过不少情况：检测到故障了，但不敢切——因为不确定备用节点的状态是不是最新的。切过去，万一数据不一致，比不切还麻烦。

1.5 本章小结

这一章，我们聊了调度系统容灾的“为什么”和“是什么”。

• 调度系统容灾，不是为了保系统，而是为了保业务。
• RPO 和 RTO 是容灾方案的“锚点”，定错了后面全白干。
• 容灾等级不是越高越好，匹配业务需求才是王道。
• 调度系统容灾的核心逻辑：检测 → 决策 → 恢复。