3.7 KiB
3.7 KiB
title, tags, created
| title | tags | created | |||||
|---|---|---|---|---|---|---|---|
| RPO (Recovery Point Objective) |
|
2026-04-25 |
RPO (Recovery Point Objective)
RPO (Recovery Point Objective) 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。
Definition
"RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly
RPO 是灾备规划的核心指标之一，与 RTO（恢复时间目标）共同构成灾备目标体系。
Key Characteristics
| 维度 | 说明 |
|---|---|
| 衡量对象 | 数据丢失量（Data Loss Amount） |
| 测量方向 | 从故障时刻向后（Backwards）追溯 |
| 关注点 | 数据完整性（How Much Data Can Be Lost） |
Example
如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则：
- RPO = 1 小时：这意味着过去 1 小时内的数据可能丢失
- 2:00 到 3:00 之间发生的所有事务都面临丢失风险
RTO vs. RPO
RTO 和 RPO 衡量的是不同维度，必须同时优化：
| 场景 | RTO 目标 | RPO 目标 | 说明 |
|---|---|---|---|
| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 |
| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 |
| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 |
| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 |
关键：不能只优化其中一个指标。
- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效
- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效
Feature Flag 对 RPO 的保护
传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 Feature Flag 回滚不丢失数据：
- Feature Flag 切换只改变代码执行路径，不触碰数据层
- Kill Switch 关闭故障功能时，用户正在提交的数据不受影响
- RPO 在整个 Feature Flag 操作期间始终保持近零
Tiered RPO Targets
| Tier | 场景 | RPO 目标 | 说明 |
|---|---|---|---|
| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 |
| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 |
| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 |
实现手段
| 方法 | RPO 效果 | 说明 |
|---|---|---|
| 无备份 | ∞ | 完全不可接受 |
| 每日备份 | 24 小时 | 成本低，RPO 差 |
| 每小时备份 | 1 小时 | 中等成本和效果 |
| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 |
| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 |
RPO 与 RTO 必须协同
最佳实践是同时设定 RTO 和 RPO，并将 Feature Flag / Kill Switch 纳入灾备工具链：
- RTO 短 → 系统快速恢复
- RPO 小 → 数据损失少
- Feature Flag → 两者兼得的性价比方案
Related Concepts
- RTO — Recovery Time Objective，停机时间指标
- Disaster Recovery — 灾备策略，RTO/RPO 是其核心目标
- Feature Flag — 保护 RPO 的配置级热修复机制
- Kill Switch — 关闭故障功能，保护数据不被继续破坏
- High Availability — 高可用性，降低 RPO 的基础设施
- Data-Governance — 数据治理，包含 RPO 策略