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）、记忆修复前备份。
This commit is contained in:
admin committed
commit
ce8e6ceed9
396 files changed
+66045
No files matched your search
@@ -0,0 +1,121 @@
|
||||
# 调研：这类游戏的网络特征 · 单房间群聊的人数上限
|
||||
|
||||
> 日期：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 参与的放大系数实测 | ⚠️ 未实测 |
|
||||
Reference in new issue
Block a user