RPO，是灾难发生时，..多可能丢失的数据时间窗口；RTO，是从业务中断到恢复对外正常访问的时长。异步容灾本身是异步增量复制，主站写入成功就返回给用户，数据后续再同步到贵阳灾备节点，天然存在复制延迟，和同步复制、本地快照要分开评估。

建站业务可以分成两类，一类是纯展示官网，几乎没有写入，只有页面静态资源；另一类是带表单、留言、订单、会员的动态建站，有持续数据写入，两者评估标准差别很大。

纯展示类企业官网，页面改动频率很低，很少新增数据。RPO 可以放宽到小时级甚至按天，每日凌晨全量同步一次到贵阳异步容灾节点，就算主站故障，..多丢失当天还没同步的少量修改内容。RTO 主要取决于灾备环境是否提前就绪，源码、Nginx/IIS 配置、域名解析记录是否预配置好，一般在 30 分钟到 2 小时。这类业务对 RPO 容忍度高，异步容灾性价比很高。

带表单、会员、订单、后台提交的动态建站，数据是核心。MySQL 数据库异步主从复制，正常链路稳定时，复制延迟通常在 1 秒～30 秒，也就是 RPO 窗口几十秒。一旦专线链路拥堵、断连，增量 binlog 堆积，RPO 窗口会持续拉大，链路恢复后集中同步流量还会冲击灾备节点。RTO 由几个环节叠加：故障发现告警时间、切换研判时间、数据库切换、程序配置、DNS 解析切换。如果灾备节点常年待机、配置和主站保持一致，DNS 用 TTL 较短的解析记录，RTO 一般控制在 5～15 分钟；如果灾备环境需要临时部署、导入数据，RTO 会拉长到几十分钟甚至更久。

评估的时候不能只看理想空载状态，要把故障场景拆开测算。链路中断是高频场景，专线断开之后，主站继续产生新数据，这些数据无法同步到贵阳灾备，直到链路恢复。这个窗口就是你的极限 RPO，需要设置复制延迟告警，一旦同步延迟超过阈值就通知运维。勒索病毒、删库属于逻辑故障，异步复制会跟着把删除、加密操作同步到灾备，这种场景异步容灾救不了，必须叠加本地定时快照，快照单独保留多版本，快照的 RPO 单独设置，比如 15 分钟一次快照。

组网层面，主站和贵阳灾备之间走专线传输复制流量，不和网站 BGP 访问带宽共用，避免用户访问流量挤占同步通道，放大复制延迟。监控指标要持续采集：binlog 延迟、未同步事务数量、专线带宽使用率、灾备服务器磁盘水位。同时要定期做切换演练，很多时候复制状态显示正常，但是灾备节点缺少程序依赖、WAF 策略、SSL 证书，真实切换时 RTO 远超预期。

（声明：本文来源于网络，仅供参考阅读，涉及侵权请联系我们删除、不代表任何立场以及观点。）