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 参与的放大系数实测	⚠️ 未实测