admin/dsh_ai1net_server
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
318430c9e9c969bebe92f06879d6ca583b509c80
dsh_ai1net_server/docs/覆盖网络/覆盖网络_千台全场景推演_20260916.md
T
admin ce8e6ceed9 chore(工作区): 纳入版本控制基线（回收 411 MB 过程产物） 
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复：
- 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录）
- tmp/（32.4 M，按接续棒命名的过程临时区）
- .workbuddy/tmp/（39.5 M）
- 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物）
- tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留

入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与
接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、
.workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。

排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、
打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
2026-09-24 07:51:03 +08:00

11 KiB
Raw Blame History

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 并发重连时控制面 / 中继的实际表现 ⚠️ 未压测
Reference in new issue View Git Blame Copy Permalink