# 1000 台异构设备 · 全场景互联推演（文字推演 v3）

> 日期：2026-09-16 ｜ 性质：**文字推演**（纸面演算，未接入任何机器；数值标"实测"的除外，其余为推算）
> 承接：`覆盖网络_百台规模推演_20260916.md`(v2) · `覆盖网络_全球架构复盘_20260916.md` · `覆盖网络_游戏专项_MMORPG与MUD_20260916.md` · `覆盖网络_调研_游戏网络特征与群聊上限_20260916.md`
> 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

---

## 0. 推演设定

### 0.1 设备构成（1000 台，异构）

| 类 | 场景 | 台数 | 打洞成功率（估） | 可直连 | **需中继** |
|---|---|---|---|---|---|
| A | 云服务器（**专属公网 IP**） | 100 | 不需打洞 | 100 | 0 |
| B | 家庭固定宽带 | 300 | ~90% | 270 | 30 |
| C | 共享公网 IP / CGNAT | 200 | ~40% | 80 | 120 |
| D | 移动网（4G/5G） | 150 | ~10% | 15 | 135 |
| E | 企业 / 校园局域网（常封 UDP） | 150 | ~20% | 30 | 120 |
| F | VPN 全隧道 | 100 | ~20% | 20 | 80 |
| | **合计** | **1000** | | **515** | **485（48.5%）** |

⇒ 与"按 **45%** 设计中继容量、按 **55%** 留余量"的口径吻合。

### 0.2 应用构成（跑在这 1000 台上）

| 应用 | 规模设定 |
|---|---|
| **游戏服**（MMORPG/传奇/MUD） | **40 服**，每服 300 玩家（玩家为**外部客户端，不计入这 1000 台**） |
| **群聊房间** | 200 个房间 × 平均 50 人；**另有 1 个 1000 人大房**（压测极端） |
| **Agent** | 平均每台 2 个 ⇒ **2000 个 agent** |
| **备份** | 200 台做每日增量 |
| **迁移** | 每月数次，单次 ~46.3 MB（不可再生数据口径） |

### 0.3 关键实测锚点（非推算）

- 实例首屏含客户端合并脚本 **11,363,655 B ≈ 10.8 MB**（含 ETag/304 短路）
- 跨云链路实测 **~22 KB/s**（下界参考）
- 心跳间隔 **20 s**（沿用现有隧道自愈定时器）

---

## 1. 设备类型 × 应用 的分工矩阵

| 设备类型 | 台数 | 典型角色 | 关键约束 |
|---|---|---|---|
| **云服务器（专属 IP）** | 100 | **骨干 / 中继 / 游戏服 / 备份汇聚** | 上行按量计费 ⇒ 别当默认中继 |
| **家庭固定宽带** | 300 | 常用客户端 / **服主** / 备份目标 | **上行小（20–50 Mbps）**、IP 会变 |
| CGNAY / 共享 IP | 200 | 常用客户端 | **必走中继** |
| 移动网 | 150 | 移动端客户端 | **抖动大**、切网频繁 |
| 企业 / 校园网 | 150 | 办公客户端 | **封 UDP ⇒ 必须有 443/TCP 兜底** |
| VPN 全隧道 | 100 | 远程办公 | 打洞被破坏 ⇒ 检测即降级中继 |

---

## 2. 分场景推演

### S1 · 冷启动（1000 台加入）

| 项 | 数值 | 判读 |
|---|---|---|
| 控制面心跳（稳态） | 1000 / 20 s = **50 req/s** | 可忽略 |
| **同时上线（惊群）** | 瞬时 **1000 并发** | 必须**令牌桶**（如 10/s ⇒ 100 s 接纳完）+ 退避抖动 |
| **首屏 bundle** | 1000 × 10.8 MB = **10.8 GB** | ⚠️ **单次最大流量** ⇒ 内容寻址 + 分级缓存（区域边缘 + 局域网共享）；已加载走 304 |

⇒ 冷启动的唯一大坑是 **10.8 GB 一次性拉取**，不是心跳。

### S2 · 稳态（无大任务）

| 流量 | 计算 | 结果 |
|---|---|---|
| 控制面心跳 | 1000 / 20 s | **50 req/s** |
| **presence（200 房 × 50 人）** | `200×50×49 / 60` | **≈8,200 次/秒** |
| **presence（那个 1000 人大房）** | `1000×1000 / 60` | **≈16,700 次/秒** |
| 群聊消息（全局 50 msg/s，均扇出 50） | `50×50` | 2,500 投递/秒 |
| 大房消息（1 msg/s） | `1×1000` | 1,000 投递/秒 |

> ⚠️ **本轮最重要的量化结论之一**：**presence 比消息早爆一个量级** ——
> 1000 人大房的 presence（**16,700/s**）是其消息扇出（1,000/s）的 **16 倍**；连"200 个普通房加起来"（8,200/s）都被它一个人超过。
> ⇒ **第一瓶颈是 presence，不是消息**；大房必须**单独策略**（只推在线/离线态 + 批合并 + 降频）。

### S3 · 游戏（40 服 × 300 玩家）——**"服放哪"决定中继成本差一个数量级**

| 部署方式 | 每服上行 | 中继承载 | 结论 |
|---|---|---|---|
| **服放有公网 IP 的节点（L1）** | 300 × 10 KB/s = **24 Mbps** | **0** | ✅ **玩家直连，中继完全不承载** |
| 服放家宽 / CGNAT 后（假设 40 服中 25 服） | 同上 | **25 × 24 Mbps = 600 Mbps 常驻** | ⚠️ 单台 1 Gbps 中继都不够，还要留峰值 |

- 峰值（攻城战）：带宽翻倍 ⇒ 48–80 Mbps/服 ⇒ 25 服同时攻城 = **1.2–2.0 Gbps** ⇒ 必须错峰 + 配额。
- 抖动门槛：**jitter < 20 ms**，否则位置与战斗 desync ⇒ **中继路径必须按抖动评估，不能只看带宽**。

> ⭐ **结论：把游戏服放在有公网 IP 的节点上（= 骨干层），是本方案里收益最大的一次选择** —— 中继流量从 600 Mbps 直接降到 0。

### S4 · 群聊极端房（1000 人）

| 项 | 数值 |
|---|---|
| presence | **16,700 次/秒** ← 瓶颈 |
| 消息扇出（1 msg/s） | 1,000 投递/秒（可承受） |
| 必须做的 | presence 只推在线/离线 + 批合并 + 降频；消息**切游标拉取**；**慢速模式**；RBAC 缓存 |

⇒ 单房间建议上限按**扇出预算**定义，而不是人数（见调研稿 §2.4）。

### S5 · Agent 风暴（**本方案独有的放大源**）

- 2000 个 agent（平均每台 2 个）。若那个 1000 人房里聚集 200 个 agent：
  - 无约束 ⇒ agent 互相激发 ⇒ 消息量**指数增长**（A 说 → B 回 → …）⇒ 房间被瞬间打满。
- 必需四条硬约束：**① 禁止 agent 直接触发 agent（只有人的消息能触发）② 每 agent 每 N 分钟最多 M 条 ③ 发言后静默期 ④ 房间级 agent 数上限**（建议 ≤ 房间人数 / 10）。

> ⇒ **对本方案而言，单房间的实际上限由「presence + agent 预算」决定**，消息扇出还在其次。

### S6 · 备份窗口（每晚 02:00）

| 口径 | 计算 | 结果 |
|---|---|---|
| 200 台 × 增量 50 MB | 10 GB | — |
| 摊到 1 小时 | 10 GB / 3600 s | **22 Mbps**（可接受） |
| **集中在头 10 分钟** | 10 GB / 600 s | **136 Mbps** ⚠️ 会挤占游戏与聊天 |

⇒ 必须**抖动窗口 + 低优先级队列**（交互流量优先）。

### S7 · 迁移（大文件）

- 单次 46.3 MB；若链路只有 22 KB/s ⇒ **35 min**（这是慢链路下界）。
- 手段：分片多流 / 先压缩 / 惰性拉取 / 经对象存储中转。
- 10 台同时迁移 ⇒ 必须配额，不能占满中继。

### S8 · 中继故障

- 中继 A 挂 ⇒ 其承载部分（假设 485 的 1/3 ≈ **160 台**）需切换。
- **160 并发重连** ⇒ 无退避就会打垮备用中继 ⇒ 必须**指数退避 + 抖动**。
- 若全网只 2 台中继：切换后单台要扛 485 台 ⇒ **必须 N+1 且有余量**，最好由 L1 节点组成中继池。

### S9 · 控制面重启

- 1000 台重连 ⇒ **1000 并发** ⇒ 令牌桶 + 退避。
- **数据面必须独立存活**（已建立的连接不受影响）—— 这是控制面/数据面分离的核心价值。

### S10 · 区域性网络突变

- 某运营商调 NAT / 某区域断网 ⇒ 整类节点同时回中继 ⇒ **中继瞬时翻倍**。
- ⇒ 中继容量必须按 **55%（而不是 48.5%）** 预留，且要能在数分钟内横向加中继。

### S11 · NAT 表溢出

- 同一企业网 / 同一家庭多台设备同时向同一目标打洞 ⇒ 该 NAT 表被打满 ⇒ 全屋（全办公室）掉线。
- ⇒ **每 NAT / 每子网打洞并发上限** + 分散端口 + 收敛探测频率。

---

## 3. 1000 台流量预算总表（**全案最重要的一张表**）

| 流量 | 频率 | 单次 | 1000 台放大 | 上限手段 |
|---|---|---|---|---|
| 控制面心跳 | 20 s | ~100 B | **50 req/s** | 懒心跳 + 合并上报 |
| **presence（普通房）** | 变化驱动 | 小 | **≈8,200 次/s** | 订阅裁剪（只推可见）+ 批合并 |
| **presence（1000 人大房）** | 变化驱动 | 小 | **≈16,700 次/s** | **只推在线态 + 降频 + 批合并** |
| 群聊消息 | 50 msg/s | 小 | 2,500 投递/s | 大房切**游标拉取** |
| **游戏流量** | 持续 | 24–80 Mbps/服 | **0（服放 L1）** / **600 Mbps（服放家宽）** | **把游戏服放到有公网 IP 的节点** |
| **首屏 bundle** | 版本发布 | 10.8 MB | **10.8 GB** | 内容寻址 + 分级缓存 + 错峰 |
| 备份 | 每晚 | 50 MB/台 | 10 GB/晚（集中时 **136 Mbps**） | 抖动窗口 + **低优先级** |
| 迁移 | 每月 | 46.3 MB/次 | 视并发 | 分片多流 + 配额 + 惰性拉取 |
| 打洞尝试 | 建连时 | 小 | 受并发上限 | **每对端 ≤4 并发** + 每 NAT 上限 |
| 更新/目录分发 | 发布时 | 大 | 爆炸 | **分层拉取**，不推送 |

---

## 4. 瓶颈排序（1000 台，按"先炸顺序"）

| 序 | 瓶颈 | 量级 | 主要处置 |
|---|---|---|---|
| 1 | **presence** | 8.2k–16.7k 次/秒 | 订阅裁剪 + 批合并 + 大房降频 |
| 2 | **游戏服放家宽时的中继带宽** | **600 Mbps 常驻**、峰值 1.2–2.0 Gbps | **把游戏服放 L1 节点** + 错峰 + 配额 |
| 3 | **首屏 bundle 冷启动** | **10.8 GB 一次性** | 内容寻址 + 分级缓存 + 令牌桶 |
| 4 | **中继抖动**（游戏可玩性） | jitter 需 <20 ms | 中继链路质量选型 + 就近 |
| 5 | 备份窗口挤占 | 集中 136 Mbps | 抖动窗口 + 低优先级 |
| 6 | 中继 / 控制面故障重连 | **160 / 1000 并发** | 退避 + 抖动 + N+1 |
| 7 | **agent 自激** | 指数级（本方案独有） | 四条硬约束 + 房间 agent 上限 |
| 8 | NAT 表溢出 | 整屋/整办公室掉线 | 每子网打洞并发上限 |
| 9 | 版本碎片 | 排障成本 | 协议版本协商 + 灰度 |

---

## 5. 推演结论（五条）

1. **控制面在 1000 台规模仍不是瓶颈**（50 req/s）；**先炸的是 presence**（16.7k 次/秒），它比消息扇出早爆一个量级。
2. **"游戏服放在哪里"是本方案最大的成本杠杆**：放有公网 IP 的节点 ⇒ 中继承载 **0**；放家宽 ⇒ **600 Mbps 常驻**。⇒ 应把骨干层与游戏服合并设计。
3. **一次性大流量只有两处**：首屏 bundle（10.8 GB/次）与备份（10 GB/晚）——**都用"分级缓存 + 错峰 + 低优先级"治，不用加带宽治**。
4. **游戏的真正门槛是抖动（<20 ms），不是带宽** —— 中继链路选型要按抖动评估。
5. **agent 是本方案独有的放大源**，必须独立预算；**单房间实际上限 = min(扇出预算, presence 预算, agent 预算)**。

---

## 6. 未验证项（勿当结论）

| # | 项 | 状态 |
|---|---|---|
| 1 | 各类设备的**打洞成功率**（本推演用的是估值表） | ⚠️ 未实测 |
| 2 | 中继链路 **jitter** 是否满足 <20 ms | ⚠️ **决定游戏可玩性，最该先测** |
| 3 | presence 收敛（订阅裁剪）的实际降幅 | ⚠️ 未实测（业界口径可达 5×） |
| 4 | agent 参与的放大系数 | ⚠️ 未实测 |
| 5 | 1000 并发重连时控制面 / 中继的实际表现 | ⚠️ 未压测 |