dsh_shenxian/dsh-server-docs/04-调整方案/109-覆盖网络-调研-游戏网络特征与群聊上限.md

# 109 · 覆盖网络 · 调研-游戏网络特征与群聊上限
- 日期：2026-09-16 ｜ 状态：📋 **规划态**（**全网调研稿**；数值均标注来源口径，未在本环境实测的一律标出）
- 来源：工作区根 `覆盖网络_调研_游戏网络特征与群聊上限_20260916.md`（正文见 附录 A）
- 层级：专项调研（**数值底座**）｜ 配套档案 **108**（游戏专项）· 104（全球架构复盘）
- 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

> **TL;DR**
> 两部分：① **这类游戏的网络特征**（传奇 / MMORPG / MUD 的每玩家带宽、同步间隔、承载、延迟/丢包门槛）；
> ② **单房间群聊的人数上限** —— 🔑 关键结论：**上限不是「人数」而是「扇出预算」**，且 **presence（N²）比消息更早爆**（1000 人房 ≈16,700 次/秒）。
> 给我们场景特有的上限：**单房间实际上限由「presence + agent 预算」决定**，不是由消息扇出决定。

## 一、目标

为容量规划提供**可引用的数值底座**：游戏侧（每玩家 2–20 KB/s、jitter<20 ms 等）与群聊侧（产品上限对照、三种分发模型的爆炸点、分档建议）。
可判定「做完了没有」＝ 两部分数值齐备 + **每条标注是行业资料口径还是本环境实测** + 结论可换算到本方案。

## 二、只读前置

| # | 事实 | 核对方式（期望输出） |
|---|---|---|
| 1 | 本档全部游戏数值均为**行业资料口径**，非本环境实测 | 逐条对照 §1.1/§1.2/§1.3 的来源标注 |
| 2 | 本环境唯一相关实测 = 跨云 **~22 KB/s**（只能作下界） | 47↔106 实测（档案 110 §三） |
| 3 | 我们场景的 presence 量级可与 §2.2 公式对齐 | `1000 × 1000 / 60` ≈ **16,700 次/秒** |
| 4 | 平台现**无「房间」抽象** ⇒ 群聊属新增能力，不是开关 | 档案 110 §五 |
| 5 | 抖动门槛 **>20 ms 即 desync** 是选路的判据来源 | 本档 §1.2 与 §1.4 第 2 条 |

## 三、范围

- **改什么**：⏳ 无实施动作 —— 本档是**调研**，产出为数值与判据，供 104/107/108/112 引用。
- **不动什么**：⛔ 本轮不动服务器、不改代码、不改文档库其它文件。
- 🟢 边界：⛔ **不得把本档的行业口径数字当作本环境实测结论**（每条均已标注）。

## 四、决策点

**已定（本档给出的判据，已被后续档案采纳）**

1. **容量按「服」算，不按「玩家」算**（服务端权威 ⇒ 玩家之间不互联）⇒ 中继需求 = 服数 × 1~N。
2. **游戏侧要盯的是「抖动」不是「带宽」**（jitter > 20 ms 即 desync）⇒ 中继链路质量差（如跨云 22 KB/s）**延迟低也没用**。
3. **上行是主方向**（服务器 → 玩家）⇒ 规划时看服务器上行。
4. **单房间上限定义为「扇出预算」而不是人数** ⇒ 先定"单节点每秒可承受投递数"，再反推人数上限（可随架构演进变大，而不是魔法数字）。
5. **混合模型**（小群扇出 / 大群拉取）—— Telegram 实际做法，服务端只维护**消息时序 + 版本游标**。
6. **presence 收敛 = 只订阅「当前可见成员列表」**（Slack 做法）⇒ 流量降 5 倍。
7. **压测必须用攻城场景**（数百人同屏、带宽翻倍、同步间隔收紧到 50–100 ms），不能用平峰。

**未定**：本环境能否满足 jitter<20 ms（**未实测，且这是游戏可玩性的决定项**）。

## 五、步骤

**本档无实施步骤**（调研稿）。其**结论已被下列档案转化为可执行步骤**：
- 游戏侧 → **档案 108 §五**（服主接入 → 房间层 → 存档备份 → 跨区路由 → 会话恢复 → 副本/合服）
- presence 与群聊上限 → **档案 112 §1**（presence 七条落地做法 + 大房特殊策略）
- 数值校准 → **档案 107 §六**（未验证项转为实测项）

## 六、验收

| # | 口径 | 期望 |
|---|---|---|
| A | 游戏数值可引用 | 传奇每人 0.5–20 KB/s；MMORPG 80–800 Kbps；MUD <1 KB/s —— 均标来源 |
| B | 群聊上限对照 | Telegram 200,000 ｜ WhatsApp 2,048 ｜ Discord 单频道 100K+ 在线 |
| C | 分档建议 | ≤100 / 100–2,000 / 2,000–50,000 / >50,000 四档，各有架构要求与判据 |
| D | 本方案特有上限 | 明确「presence + agent 预算」比消息扇出更早触顶 |
| E | 未验证项透明 | 第三部分五条已列全 |

## 七、回滚

- **本档自身**：零改动 ⇒ 无回滚需要。
- ⛔ **不得作为实测依据被引用**：本档数值是**行业资料口径**，任何"已经达标"的结论都必须另有本环境实测支撑。

## 八、回报格式

执行会话（或后续校准会话）回填：① 自建服实测的每玩家带宽与同步间隔（与 §1.1 对照）② 中继链路 jitter 分布 ③ 攻城战压测结果 ④ presence 收敛实际降幅（5× 是否可达）⑤ agent 放大系数实测 ⑥ 取数时间与命令。

## 九、未验证项（勿当结论）

上述游戏数值均为**行业资料口径**，非本环境实测（**需按自建服实测校准**）｜中继链路能否满足 **jitter < 20 ms**（比带宽更关键，**未实测，且这是游戏可玩性的决定项**）｜攻城战（数百人同屏）在本方案的压测结果（**未做**）｜presence 在本方案下的实际收敛效果（5× 是否可达，**未实测**）｜agent 参与的放大系数实测（**未实测**）。

---

## 附录 A · 原始规划正文（逐字保留 · 2026-09-16）

> 以下为工作区根 `覆盖网络_调研_游戏网络特征与群聊上限_20260916.md` 的**原文全文**，仅删除其一级标题（避免与档案标题重复），
> 其余**一字未改**；本档的可判定部分以上方 8 段为准。

> 日期：2026-09-16 ｜ 性质：**全网调研稿**（数值均标注来源口径；未在本环境实测的一律标出）
> 配套：`覆盖网络_游戏专项_MMORPG与MUD_20260916.md`｜`覆盖网络_全球架构复盘_20260916.md`
> 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

---

## 第一部分 · 这类游戏的网络特征

### 1.1 传奇类（中文运维资料口径，最具体）

| 参数 | 数值 |
|---|---|
| **每人带宽** | **文字聊天 0.5 KB/s ｜ 普通战斗 2–5 KB/s ｜ 攻城战 10–20 KB/s**；另一口径：单用户平均上行 **10–20 KB/s** |
| **带宽估算公式** | `所需带宽 = 玩家数 × 100 Kbps ÷ 8`；100 人 ≥ 2 Mbps ｜ 500 人 ≥ 10 Mbps ｜ 1000 人 ≥ 50 Mbps |
| **实战推荐带宽** | 50 人 5 Mbps ｜ 200 人 10 Mbps ｜ 500 人 20 Mbps+（均含冗余） |
| **同步间隔** | 常规 **100–200 ms（5–10 Hz）**；**攻城/大型团战 50–100 ms（10–20 Hz）** |
| **引擎帧数设置** | <100 人 20 帧 ｜ ≤200 人 25–30 帧 ｜ ≈300 人 35–40 帧 |
| **发送间隔 / 缓存** | 网络发送间隔 20–30 ms；发送缓存 4096 B；接收缓存 8192 B；最大接收 1024–2048 KB/s |
| **承载** | 单区常规 **1000–5000 人**（TCP 并发 2000–10000；TPS 500–2000） |
| **延迟 / 丢包** | 延迟 ≤ **50 ms**，丢包 < 1% |
| **内存经验值** | 每 50 名玩家 ≈ 1 GB（+20% 缓冲）；1000 人区服建议 16 GB |
| **峰值场景** | **攻城战：数百玩家同屏**，带宽翻倍至 **80–100 Mbps**（1000 人口径），CPU/内存压力最大 |

### 1.2 MMORPG（英文资料口径，含 3D 参照）

| 参数 | 数值 |
|---|---|
| **每玩家带宽** | 同步 **10–20 Hz**；兴趣域实体 **50–100 个**；每实体 **20–50 B**；每包 **1–5 KB** ⇒ **单客户端 80–800 Kbps**（该上限是 3D 现代 MMO 口径；**2D/传奇类取低段**） |
| **500 人峰值** | **200–500 Mbps**；端口最低 **1 Gbps**，500+ 用 10 Gbps |
| **延迟门槛** | **< 100 ms**；⚠️ **抖动（jitter）> 20 ms 就会造成位置与战斗 desync** |
| 数据库 | MNORPG 是**持续写入**（每次拾取/战斗/交易都写）⇒ **DB I/O 是隐藏瓶颈**，>500 人建议数据库独立机器 |
| 优化 | **兴趣域（AOI）是控制带宽的"杀手锏"**；delta 压缩可再减 **50%+** |

### 1.3 MUD（文字）

- 纯文本行 ⇒ 每玩家 **< 1 KB/s**（与棋牌/回合制同档）；瓶颈是**并发连接数**（内存与文件句柄），不是带宽。
- tick 0.25–1 s；**延迟容忍度最高**，跨洲也可玩。

### 1.4 对覆盖网络的五条推论（这一节才是我们要的）

1. **带宽量级很小**：这类游戏单玩家 **2–20 KB/s**，1000 人也就 **20–100 Mbps** —— **中继扛得住**，不像视频/大文件。
2. ⚠️ **真正要盯的是"抖动"，不是"带宽"** —— 业界口径 **jitter > 20 ms 就会 desync**。⇒ 中继路径的价值不是省带宽，而是**抖动是否可控**；中继链路质量差（如实测那条 22 KB/s 的跨云）**延迟低也没用**。
3. **上行是主方向**（服务器 → 玩家），下行只是操作指令 ⇒ 规划时**看服务器上行**。
4. **容量按"服"算，不按"玩家"算**（服务端权威 ⇒ 玩家之间不互联）⇒ 中继需求 = 服数 × 1~N，而不是玩家数。
5. **攻城战就是压测基准**：数百人同屏、带宽翻倍、同步间隔收紧到 50–100 ms ⇒ **压测必须用攻城场景**，不能用平峰。

---

## 第二部分 · 单房间群聊的人数上限

### 2.1 产品上限对照（真实产品，可作为能力标尺）

| 产品 | 单房间上限 | 备注 |
|---|---|---|
| **Telegram 群组** | **200,000** 成员（频道无限） | 十万级群**切换为拉取模型**；慢速模式间隔 10 s–1 h |
| **WhatsApp 群** | **2,048** 成员 | fanout = 2047，典型"纯扇出"上限 |
| **Discord** | 单频道 **100K+ 在线**；单 guild **25M 成员**（2025-09） | 1M 并发/guild（72 台 ScyllaDB 存万亿消息） |
| 国内 IM | 数百 → 两千量级 | 口径随产品变化，此处不列精确值 |

### 2.2 为什么上限不是"人数"而是"扇出预算"

**三种模型与各自的爆炸点**：

| 模型 | 写放大 | 读放大 | 结论 |
|---|---|---|---|
| **纯扇出**（服务端逐人推送） | **极高**：20 万人群一条消息 = 20 万次写入 | 低 | **小群王道，大群自杀** |
| **纯拉取**（只存一份，各端按游标读） | 极轻 | **高**：20 万人同时上线打穿热点 | 实时性差，需长连接通知配合 |
| **混合（Telegram 实际做法）** | 小群扇出 / 大群拉取 | 中 | **推荐**：服务端只维护**消息时序 + 版本游标**，客户端按游标增量拉 |

**两个必须算的放大点（附实际数字）**：

1. **消息扇出**：20 万人 × 500 条/分钟 = **1 亿次推送/分钟** ⇒ 纯扇出不可能。
   Discord 口径：单频道 **30K 在线 × 10 msg/s = 30 万次"权限校验后的投递"/秒** —— 注意**权限检查（RBAC）是 CPU 热路径**。
2. **在线状态（presence）是 N² 问题**：每人订阅所有可见成员的状态，每次变化扇出给所有订阅者。
   ⚠️ **算一下就发现它比消息更早爆**：1000 人房、每人每分钟变化一次 ⇒ `1000 × 1000 / 60` = **≈16,700 次/秒** —— **千人房就已经是热点**。
   ✅ 业界解法（Slack）：**只订阅"当前可见成员列表"** ⇒ presence 流量降 **5 倍**。

### 2.3 关键工程机制（可直接照抄）

| 机制 | 作用 |
|---|---|
| **pub/sub 聚合** | 一条消息**每个 relay/gateway 节点只推一次**，而不是每个接收者一次 —— 这是把 30,000 次推送降下来的关键 |
| **版本游标 + 增量拉取** | 客户端只拉游标之后的增量；翻历史才回溯 |
| **presence 收敛** | 订阅范围裁剪（只可见者）+ 批量合并 + 降频 + 最终一致 |
| **RBAC 缓存 + 版本化失效** | 权限检查在热路径 ⇒ 必须缓存，且要能失效 |
| **慢速模式（slow mode）** | 把限流产品化（大群必备） |
| **客户端侧** | 本地 SQLite 缓存、成员**懒加载**、消息合并/分片渲染（防界面卡死）、多设备靠 sequence 对齐 |
| **三平面分离** | 连接平面（gateway）/ 协调平面（房间进程）/ 存储平面（写重型库 + 搜索）各自独立扩展 |
| **一致性取舍** | **最终一致（1–2 s 窗口可接受）+ 房间内严格有序** |

### 2.4 给我们的**分档建议**（回答"单房间上限"）

| 房间规模 | 架构要求 | 判据 |
|---|---|---|
| **≤ 100 人** | 纯扇出即可 | 无压力 |
| **100 – 2,000 人** | **纯扇出可行**，但必须：presence 合并 + 消息限频 + 权限缓存 | 千人房的 presence 已是热点（≈1.6 万次/秒） |
| **2,000 – 50,000 人** | **必须混合**：pub/sub 聚合 + 游标拉取 + presence 只推可见者 + 慢速模式 | 扇出成本随人数线性，聚合后按节点数而非人数 |
| **> 50,000 人** | **只能拉取模式**，公告/只读为主，presence 大幅弱化 | Telegram 20 万即此档 |

> **建议把上限定义为"扇出预算"而不是人数**：先定"单节点每秒可承受的投递数"，再由它反推房间人数上限 —— 这样上限可以随架构演进（加 gateway）而变大，而不是一个魔法数字。

### 2.5 我们场景特有的上限（**比技术扇出更早触顶**）

- **agent 入群后，真正的放大点不是消息，而是"agent 之间的互相激发"**：
  一个房间若有 K 个 agent，且不加约束 ⇒ 消息量可指数增长。
- ⇒ 必须按 **`agent 数 × 触发频率`** 单独设预算（每 agent 每 N 分钟最多 M 条 + 静默期 + **禁止 agent 直接触发 agent**）。
- ⇒ 结论：**对我们而言，单房间的实际上限由"presence + agent 预算"决定，而不是由消息扇出决定** —— 后者在千人量级还远远不是瓶颈。

---

## 第三部分 · 未验证项（勿当结论）

| # | 项 | 状态 |
|---|---|---|
| 1 | 上述游戏数值均为**行业资料口径**，非本环境实测 | ⚠️ 需按自建服实测校准 |
| 2 | 中继链路能否满足 **jitter < 20 ms**（比带宽更关键） | ⚠️ **未实测，且这是游戏可玩性的决定项** |
| 3 | 攻城战（数百人同屏）在本方案的压测结果 | ⚠️ 未做 |
| 4 | presence 在本方案下的实际收敛效果（5× 是否可达） | ⚠️ 未实测 |
| 5 | agent 参与的放大系数实测 | ⚠️ 未实测 |