源站宕机容灾方案不能等到服务器已经不可访问时才临时设计。支付、秒杀、优惠券发放等业务具有明显的瞬时流量和状态关联特征，页面恢复并不等于交易链路恢复。一个可执行的方案，应同时验证入口接管、应用运行、数据库读写、支付回调、消息队列和人工处置流程。
先明确：哪些故障需要切换
并非所有告警都应立即启动源站宕机容灾方案。单台应用服务器异常，可以通过负载均衡摘除节点解决；数据库连接池耗尽，则应先限制流量和恢复连接。只有当主要站点在多个独立探针位置持续无法提供核心服务，且已排除证书、网络出口和单节点故障时，才适合进入容灾切换判断。
用业务指标定义切换门槛
- 入口层：连续数分钟无法建立安全连接，或核心接口错误率持续超过预设阈值。
- 交易层：登录、购物车、订单创建、支付结果查询中有两项以上同时异常。
- 数据层：主库不可写、复制延迟超过业务可接受范围，或无法确认最近交易是否已经落库。
- 人工层：值班人员复核故障范围，并记录切换开始时间、当前订单号段和支付回调状态。
支付业务通常更重视数据完整性，宁可短时间关闭下单，也不应在状态不明时盲目把写请求导向备用环境。内容展示、商品浏览等流量则可以先进行静态化或只读降级。
选择适合业务的容灾架构
温备模式：成本较低，但切换需要准备
温备模式让备用应用和数据库保持可启动或部分运行状态，平时承担备份、报表或只读查询。发生故障后，需要扩容应用、恢复连接、加载配置并接管流量。它适合交易峰值不长、可以接受约十几分钟恢复时间的业务，优点是投入相对可控；缺点是切换环节较多，必须通过演练确认备用环境确实可用。
双活或多活：恢复更快，数据治理更难
双活架构让两个区域同时接收请求，适合全国性电商、持续支付和对中断敏感的服务。它可以缩短入口切换时间，但会带来库存扣减、优惠券核销、订单编号和用户会话的一致性问题。跨区域写入不应只依赖应用层“看起来成功”，还要明确冲突处理、重试规则和最终对账方式。
业务降级：不是完全恢复，而是保住核心链路
当完整站点无法恢复时，可以暂时保留商品查询、订单查询和支付结果查询，关闭推荐、评论、个性化营销等非核心功能。对秒杀活动，可采用排队页或限流页，避免备用源站刚接管就被流量再次压垮。降级规则必须提前写入配置，并说明何时开放下单、何时继续只读。
提前验证源站宕机容灾方案的操作步骤
- 建立业务清单。分别列出登录、商品读取、库存锁定、订单创建、支付发起、支付回调、退款和客服查询等链路，标注每一步依赖的服务与数据表。
- 准备隔离环境。使用与生产相近的应用版本、配置、证书、队列和数据库结构。演练支付时应使用沙箱或模拟回调，禁止把测试请求发送到真实收款接口。
- 制造可控故障。按顺序模拟应用不可用、主库只读、消息队列延迟、区域网络中断等情况，每次只改变一个主要变量，便于判断方案是否真正生效。
- 执行切换。先冻结高风险写操作或启用幂等校验，再启用备用入口，检查登录、下单、支付查询和后台管理。切换期间应保留原站点日志，避免故障排查与交易追踪脱节。
- 核对数据。比对订单数、支付状态、库存流水、退款记录和消息消费记录。对于“支付成功但订单未确认”的记录，应进入人工对账队列，而不是自动重复发起支付。
- 验证回切。主站恢复后不要立即把全部流量切回，应先让少量只读请求进入，确认数据同步、缓存失效和回调处理正常，再分阶段恢复写流量。
测试时重点看哪些结果
| 检查项目 | 合格标准 | 常见风险 |
|---|---|---|
| 入口切换 | 备用入口能够按预案接收请求，旧会话有明确处理方式 | 页面可打开，但接口仍指向故障环境 |
| 订单与支付 | 重复提交不会生成重复订单，支付回调可重试且可追踪 | 支付已完成，订单状态仍停留在待支付 |
| 库存处理 | 扣减、释放和超时关闭逻辑保持一致 | 切换前后的库存流水无法合并 |
| 回切 | 回切后新增与存量数据均能查询、更新和对账 | 缓存旧数据导致价格或库存显示错误 |
如果企业缺少跨区域网络、入口调度和持续监控能力，可在明确数据归属与服务边界后评估德讯电讯等网络与云服务供应商。推荐理由应放在可用性需求、运维支持和现有技术栈匹配上，仍需通过自身压测、故障演练和合同服务范围进行确认，不能只根据供应商名称判断方案效果。
常见问题
1. 是否必须建设双活？
不必须。交易规模较小或可接受短暂中断的系统，温备加完善备份可能更合适；只有在恢复时间要求严格、单区域故障影响较大时，才值得承担双活的一致性成本。
2. 备用站点能打开页面就算成功吗？
不算。还应验证订单写入、支付查询、回调重试、库存流水和后台操作，否则只能说明展示层恢复，不能说明交易系统恢复。
3. 演练多久做一次？
重大促销、数据库版本升级或架构调整前应专项演练；稳定运行的系统通常至少每季度检查一次关键切换链路，频率还应根据业务风险和变更量调整。
4. 如何避免重复扣款？
为订单和支付请求设置全局幂等标识，支付结果以服务端查询和回调为准，并将超时、重复回调和状态不一致记录到对账队列中。源站宕机容灾方案只有覆盖这些细节，才真正适用于支付和大促场景。
最终，源站宕机容灾方案的验收标准不是“备用页面出现了”，而是故障期间交易状态可追踪、数据能够核对、流量可以受控恢复，且每个关键动作都有明确负责人。
