2. 容灾基础概念

在核心银行系统的容灾建设中，业务部门最常问的两个问题是：“系统多久能恢复？”和“会丢多少数据？”这两个问题分别对应容灾领域最基础、也最容易被混淆的两个指标：RTO与RPO。理解它们，是理解后续所有容灾架构、切换策略和演练方案的前提。

一、核心原理：RTO 与 RPO 的定义

RTO（Recovery Time Objective，恢复时间目标）指灾难发生后，从业务中断到系统恢复对外服务所允许的最长停机时间。它衡量的是“恢复速度”，单位通常是分钟或小时。例如 RTO=30 分钟，意味着故障发生后半小时内必须恢复交易能力。

RPO（Recovery Point Objective，恢复点目标）指灾难发生时，系统允许丢失的数据时间跨度。它衡量的是“数据新鲜度”，即恢复后的数据对应到故障前的哪个时间点。例如 RPO=0 表示不允许丢数据，RPO=5 分钟表示最多丢失最近 5 分钟的交易。

在核心银行场景中，RPO 往往比 RTO 更敏感。账务数据一旦丢失，意味着对账不平、客户资金错乱，其修复成本远高于停机本身。因此核心账务系统通常要求 RPO≈0，而查询类、报表类系统可接受分钟级 RPO。

二、可用性等级：从 99% 到 99.999%

可用性等级用年度停机时间衡量系统稳定程度，是容灾投入的直接标尺。可用性每提升一个“9”，成本往往呈数量级增长。

需要强调的是，可用性等级是结果指标，RTO/RPO 是过程指标。设计时先确定可用性目标，再反推 RTO/RPO，最后选择容灾模式，而不是反过来。

三、容灾模式：冷备、温备、热备与多活

四种容灾模式的本质区别在于：备用环境是否运行、数据是否实时同步、切换是否需要人工介入。

• 冷备（Cold Standby）：备用机房只有硬件和基础环境，系统和数据均未部署或仅在介质上保存。故障时需现场安装、恢复数据、启动系统。RTO 通常数小时至数天，RPO 取决于备份周期，成本最低。
• 温备（Warm Standby）：备用环境已安装系统并定期同步数据，但服务未启动或仅部分启动。切换需人工确认和启动步骤。RTO 约 30 分钟至数小时，RPO 分钟级至小时级。
• 热备（Hot Standby）：备用环境实时运行，数据通过同步或半同步复制保持接近一致，可自动或快速手动切换。RTO 分钟级，RPO 秒级甚至 0，成本较高。
• 多活（Multi-Active）：多个站点同时对外提供服务，流量按策略分发，数据双向或多向同步。单站点故障时流量自动漂移，RTO 接近 0，RPO≈0，但架构复杂度、数据冲突处理成本最高。

四、场景与误区复盘

某银行核心系统曾宣称“同城双活、RTO=0”，但在一次真实切换演练中耗时 47 分钟。复盘发现：数据库虽为双活，但应用层连接池、DNS 切换、批量任务锁均需人工干预，实际 RTO 被这些“非数据库环节”拉长。这说明 RTO 是端到端指标，不能只按单个组件估算。

另一个常见误区是把 RPO=0 等同于“数据绝对不丢”。在异步复制下，即使配置了 RPO=0 目标，故障瞬间仍可能丢失在途事务。真正的 RPO=0 需要同步复制或共识协议支撑，且会带来写延迟上升的代价。

# 容灾切换演练记录示例（核心账务系统）
演练时间：2024-06-15 02:00
故障注入：主中心数据库实例不可用
切换方式：手动确认 + 脚本编排
实际RTO：18分32秒（目标≤30分钟）
实际RPO：0秒（同步复制，无数据丢失）
数据校验：借贷平衡校验通过，总账与明细一致
问题项：应用连接池重连耗时6分钟，需优化

综合来看，RTO、RPO、可用性等级与容灾模式构成一个层层递进的设计链条：业务连续性要求决定可用性等级，可用性等级拆解为 RTO/RPO，RTO/RPO 再驱动容灾模式选型。掌握这条链条，才能在后续的多活架构与故障切换实战中做出有依据的决策。