admin
ce8e6ceed9
回收 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）、记忆修复前备份。
8.5 KiB
8.5 KiB
调研：这类游戏的网络特征 · 单房间群聊的人数上限
日期：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 对覆盖网络的五条推论（这一节才是我们要的）
- 带宽量级很小：这类游戏单玩家 2–20 KB/s，1000 人也就 20–100 Mbps —— 中继扛得住，不像视频/大文件。
- ⚠️ 真正要盯的是"抖动"，不是"带宽" —— 业界口径 jitter > 20 ms 就会 desync。⇒ 中继路径的价值不是省带宽，而是抖动是否可控；中继链路质量差（如实测那条 22 KB/s 的跨云）延迟低也没用。
- 上行是主方向（服务器 → 玩家），下行只是操作指令 ⇒ 规划时看服务器上行。
- 容量按"服"算，不按"玩家"算（服务端权威 ⇒ 玩家之间不互联）⇒ 中继需求 = 服数 × 1~N，而不是玩家数。
- 攻城战就是压测基准：数百人同屏、带宽翻倍、同步间隔收紧到 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 实际做法） | 小群扇出 / 大群拉取 | 中 | 推荐：服务端只维护消息时序 + 版本游标，客户端按游标增量拉 |
两个必须算的放大点（附实际数字）：
- 消息扇出：20 万人 × 500 条/分钟 = 1 亿次推送/分钟 ⇒ 纯扇出不可能。 Discord 口径：单频道 30K 在线 × 10 msg/s = 30 万次"权限校验后的投递"/秒 —— 注意权限检查（RBAC）是 CPU 热路径。
- 在线状态（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 参与的放大系数实测 | ⚠️ 未实测 |