章
目
录
聊聊灾备设计下的两大指标：RPO、RTO是一道分布式常见面试题，因为在系统的高可用和灾备设计中，RPO和RTO是两个绕不开的关键指标。这俩指标不仅关系到系统出现故障时的应对策略，还能直观反映出系统的可靠性和性能。今天咱就来深入聊聊这两个指标。
什么是RPO
RPO（Recovery Point Objective），简单来说，就是系统故障时可能丢失数据的最长时间范围，是个衡量数据丢失情况的指标。大家都知道，数据是系统的核心，丢数据那可是大事儿，谁都不想遇到。所以，不少公司都会采取各种数据备份手段，像全量备份、增量备份、差异备份等等，就是为了减少数据丢失的风险。
打个比方，要是系统设定每6个小时进行一次数据备份，那么在极端情况下，系统故障时最多就会丢失6个小时的数据，这时候RPO就是6小时。不过实际情况中，丢失的数据量和时间可不是固定的。要是系统在夜里凌晨用户访问少的时候挂了，那这6个小时产生的数据量肯定比白天少很多；而且说不定系统刚备份完没多久就出故障了，那可能也就只丢了一两个小时的数据。所以说，RPO虽然是个参考指标，但具体的丢失数据情况还得结合系统故障的时间点来判断。
什么是RTO
RTO（Recovery Time Objective）关注的则是系统从故障不可用到恢复正常运行所花费的时间。之前咱们提到的“两地三中心”“祖宗灾备”这些方案，主要目的就是降低RTO。
像很多互联网大厂、银行以及企业官网这类对稳定性要求极高的平台，它们对RTO的要求近乎苛刻，甚至希望能达到零。这可不是说它们的系统永远不会出故障，而是当故障发生时，哪怕是遇到自然灾害这种极端情况，它们都有备用节点或者冗余节点能迅速顶上，实现无缝切换。有些互联网公司宣称自家站点能达到“五个九”甚至更高的可用性，就是因为它们的RTO很短，系统故障后能快速恢复。对用户来说，可能就只是感觉稍微卡顿了一下，几乎不影响正常使用。
设计时的考量
从系统可用性的角度来看，RPO和RTO当然是越低越好，这意味着系统的可用性更强，用户体验也更好。但在实际的架构设计中，可不能盲目追求低RPO和RTO。
比如说，如果频繁进行数据备份来降低RPO，那备份数据存哪儿呢？得有足够的存储空间才行。要是追求接近零的RTO，整个灾备体系都得升级。应用程序设计、架构、微服务框架，还有数据同步机制等都得重新规划。在冗余设计方面，不能再用简单的冷备方案，至少得采用温备，甚至热备。这一系列操作下来，成本会大幅增加，公司还得考虑运营利润能不能覆盖这些成本。
总之，在设计灾备方案时，得综合权衡RPO和RTO，找到一个符合公司实际业务需求和成本预算的平衡点。要是大家对RPO和RTO还有啥疑问，欢迎在评论区留言，咱们一起讨论！
