【运维发布】异地容灾：双机房的切换预案

实战应用：用在哪里

机房级的故障（断电、光纤断、火灾）是小概率大杀伤：单机房的容灾挡不住机房本身出事。异地容灾把游戏的完整能力复制到第二个机房，切换预案让机房级的灾难从灭绝事件降级为一次可预期的迁移。

双机房的架构

---双机房的数据同步状态
function DrReplica.status()
    return {
        primary = "bj",
        standby = "sh",
        -- 数据同步的延迟秒数
        lag = DBReplica.lagSeconds(),
        -- 同步的健康状态
        healthy = DBReplica.lagSeconds() < 30,
    }
end

---切换的决策：主机房不可用的判定
function DrReplica.shouldFailover()
    local s = DrReplica.status()
    -- 主机房失联超过 120 秒且备用机房健康
    if Primary.offlineSince()
        and Primary.offlineSecs() > 120
        and s.healthy then
        return true
    end
    return false
end

双机房的同步是容灾的命脉：主机房写、备用机房实时复制，延迟 30 秒内的健康线是切换信心的来源。切换的判定双条件：主机的失联超 120 秒（避开网络抖动的误判）加备机的健康——两个条件缺一不可，误切换的代价与不切换一样大。数据的同步模式取舍：同步复制零丢失但性能减半、异步复制流畅但可能丢秒级数据——游戏的取舍是异步加关键表的同步（支付的订单表同步复制），资损的零容忍与体验的流畅各保各的。

切换的执行

---切换的执行清单
function DrReplica.failover()
    Ops.alert("开始机房切换")
    -- 第一步：备用库提升为主库
    DBReplica.promote("sh")
    -- 第二步：域名切到备用机房
    Dns.switch("game.chuan2.cn", "sh")
    -- 第三步：缓存与预热
    Warmup.run()
    -- 第四步：冒烟验证
    if Smoke.run() then
        Ops.alert("切换完成，服务已恢复")
        return true
    end
    Ops.alert("切换后冒烟失败，人工介入")
    return false
end

切换的执行四步走：备库升主、域名切流、缓存预热、冒烟验证——每一步的自动化让切换的耗时控制在 10 分钟内，人工只做决策不做操作。切换的演练季度一次：真把流量切到备用机房跑半天，预案的正确性只在真实的切换里得到验证，没演练过的切换预案等于没有。切换的回切预案同样重要：主机房恢复后的切回要走同样的流程，切回的窗口选在低峰。RTO 与 RPO 的指标量化：切换的耗时目标是 10 分钟（RTO），数据丢失的窗口是 30 秒（RPO），两个数字是容灾的承诺也是演练的验收线。

验证与监控

同步延迟的分钟级监控，延迟的持续走高是切换窗口关闭的预警；演练的 RTO 与 RPO 的实测归档，预案的承诺用演练的数据背书。

踩坑记录

同步的延迟曾经在备份任务高峰时超标，双机房的任务错峰让延迟回线。切换的 DNS 曾经缓存了旧解析，玩家的域名指向老机房两小时，TTL 的预调短。切换后的注册数据曾经双写混乱，主备的角色映射表在切换期冻结写入。

上线要点

双机房的配置与版本保持一致，备机的过期是切换时的地雷。切换的决策人授权清单写明：谁宣布切换、谁确认恢复。演练与预案的版本绑定，架构的每次演进同步更新预案。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。