11.12 容量与成本决策：连接、群扇出、历史留存怎样一起算
返回第十一卷 · 工作负载：11.04 · 压测：11.07 · SLO：11.08 · 复盘：11.11
11.12 容量与成本决策：连接、群扇出、历史留存怎样一起算
DeepTutor 八节初稿经技术与教学审阅后的静态课程。连接、速率、字节、保留、实例能力和成本均是虚构纸上假设，没有运行 Go、IM、数据库、队列、压测、集群或站点，也没有查询真实云价格。当前 S2
/v1的正文仍非空且最多 6 UTF-8 B、原始 HTTP 请求正文最多 4096 B、同 ID 重复 409、非成员目标隐藏 404、成功200 accepted_in_memory仅是本进程内存受理；未来 S3/v2的stored_in_teaching_db是提议且仍为 6 B，R9 6→9 B 待审。09.02 当前合同
一、容量问题从“要保证什么”开始
第十一卷从测量、分布、诊断走到压测、SLO、级联故障与复盘。现在要回答一个常见业务决策：“未来教学 IM 如果支持一万条在线连接、群聊、多设备和离线恢复，怎样估算资源、留故障余量，并说明成本值得花在哪？”不能只按在线人数买网关，也不能只用单实例最高 QPS 决定可靠性。先固定用户结果：A 收到现行 S2 内存受理、未来 S3 权威消息保存、B 设备收到、B 离线后从有权历史补拉，分别是不同确认点。11.01 业务结果 · Google SRE：具体系统设计与容量
这是一份容量决策书，不是生产部署方案。它要有场景、单位、假设、算式、独立资源瓶颈、故障时余量、候选方案和待验证证据。若业务改变群规模、设备数、历史保留或 SLO，重新算相应项；不能让上月的“100 条消息/秒”成为所有场景通用的容量标签。Google SRE 将需求预测、负载实验和实际服务容量关联起来，也强调可靠性有冗余与工程机会成本。Google SRE：容量规划 · 可靠性与成本取舍
二、连接、活跃与群扇出是不同单位
沿 11.07 的同一简化纸上基线：有 10,000 条设备连接，假设一条连接暂对应一个活跃统计对象；其中 2% 活跃，为 10,000×0.02=200 个活跃连接；每个活跃连接平均每秒发 0.1 条入站消息，则 200×0.1=20 条入站消息/秒。实际多设备用户与连接不是一对一，后续要按设备和用户分别取证。11.07 工作负载单位
设这 20 条在未来群聊链路里每条恰好有 50 位目标成员、每人 2 台目标设备，且每台都生成独立任务、没有在线过滤/合并/重试：设备任务速率 20×50×2=2,000 项/秒。这只是条件计算值，不是当前 S2 的真实扇出、生产上界或成功交付数。若把单个未来设备任务的完整封装假设为 512 B，纯任务载荷速率 2,000×512=1,024,000 B/s≈0.977 MiB/s；当前 S2 消息正文最多 6 B 与未来任务封装 512 B 不是同一字段。TLS、协议帧、重试、复制、网卡方向和峰值都还没算。07.06 消息与事件抽象
再假设连接在进程里平均各占 32 KiB，则 10,000×32 KiB=320,000 KiB=312.5 MiB。它只估了一个进程内连接态分量，未计 Go 堆其他对象、goroutine/线程栈、TLS、内核 socket 缓冲、队列、共享缓存与峰值；不能据此说“312.5 MiB 就能跑一万连接”。CPU、文件描述符与握手/重连尖峰也可能先于内存成为瓶颈。03.06 连接驻留预算 · 11.05 RSS 与 Go 内存
| 量 | 本题结果 | 不能混成 |
|---|---|---|
| 在线设备连接 | 10,000 条 | 10,000 条消息/秒 |
| 活跃连接 | 200 条 | 200 个独立用户，除非有映射证据 |
| 入站权威消息候选 | 20 条/秒 | 2,000 条新权威消息 |
| 设备任务 | 2,000 项/秒 | 2,000 次应用 ACK |
| 连接态内存分量 | 312.5 MiB | 进程总 RSS 或容器内存 |
三、权威历史、E9 和设备任务各有存储账本
假设未来业务要求保存权威消息，纸上入站速率一直维持 20 条/秒。一天 20×86,400=1,728,000 条。若每条权威记录连同本题假设的元数据平均占 1 KiB，则逻辑原始量 1,728,000 KiB÷1,048,576≈1.648 GiB/天。若未来业务另行批准历史保留 30 天且每天同速率，纸上原始记录约 1.648×30≈49.44 GiB。本课程尚无已批准的“30 天历史保留合同”；它只是为容量练习提出的情景。真实 DB 还需索引、WAL、页/碎片、副本、备份、迁移与查询读放大，不能把 49.44 GiB 当账单或磁盘总需求。06.01 权威消息身份 · 06.09 日志/恢复
再假设未来教学 outbox 对每条入站权威消息发一个 E9 类事件，事件完整封装平均 512 B，纸上 broker 保留 24 小时：原始事件量 20×86,400×512 B=884,736,000 B≈0.824 GiB。若讨论把这份事件流保留从 24 小时增至 48 小时，在同速率且无额外放大的条件下约 1.648 GiB 原始数据。它不含 broker 副本、索引/分段、预留空盘、重试、不同事件类型，也不是每秒 2,000 个设备任务都被 broker 存一份。07.10 outbox
这两本账服务不同恢复目标：m-9/seq9 的权威历史来自有权限的数据库；E9 是派生链路的事件。B 离线 25 小时，超过纸上 broker 24 小时保留，不能只靠 E9 仍在 broker 补全，须按成员权限从权威历史查缺口。把 broker 延到 48 小时可能降低这一种离线时长造成的事件过期风险，却不解决更久离线、broker 故障、权限错误或权威消息丢失；权威历史恢复路径仍需要验收。07.12 24/25 小时反例
四、N−1 算式只是故障容量的起点
设隔离实验未来真的证明：在某个固定的连接、群规模、设备数和数据库依赖组合下，单个网关可长期稳定处理 100 条入站消息/秒，并满足约定用户结果。另设不同于基线 20/s 的目标峰值为 150 条入站消息/秒。三实例正常名义能力 3×100=300/s；失去一个后为 2×100=200/s，相对峰值有 50/s 名义余量。若只有两实例，失去一个后只剩 100/s<150/s，不满足这个 N−1 算术条件。11.07 N−1
| 纸上实例数 | 正常名义上限 | 失一后的名义上限 | 对 150/s 峰值 |
|---|---|---|---|
| 2 | 200/s | 100/s | 不满足 N−1 算术 |
| 3 | 300/s | 200/s | 名义多 50/s；实际仍待验 |
50/s 不是全面可靠性余量。 节点退出后连接迁移可能同时带来握手与历史补拉；一个大群可能只落在一个分片；DB、broker、共享缓存或出口带宽可能先满；同样的 150 条/秒若群规模从 50 变 500，设备任务会大幅增加。需要 11.07 所述相同工作负载的长稳、热点、单节点故障和恢复实验，分别看 A 受理、未来 S3 持久、B 设备与历史查询。08.05 热点与再平衡 · 11.09 恢复风暴
五、增长情景一次只改变一个主要前提
容量表要让读者看得出哪项需求使哪项资源先变紧。下面各行均从同一基线单独改变，不互相叠加：
| 单独变化的纸上情景 | 重新手算的量 | 首先要验证的资源/业务问题 |
|---|---|---|
| 基线：10,000 连接、2% 活跃、0.1 条/s、50 人×2 设备 | 20 入站/s，2,000 任务/s，连接态 312.5 MiB | A 受理、未来 B 设备与队列分别达标吗？ |
| 仅连接翻倍，活跃比和人均发送不变 | 20,000 连接；40 入站/s；若群仍 50×2则 4,000 任务/s；连接态 625 MiB | 连接/握手、文件描述符和网关内存先满吗？ |
| 仅目标群从 50 人变 500 人，原入站仍 20/s | 20×500×2=20,000 任务/s | 热点分区、网关出口、慢设备是否先饱和？ |
| 仅历史保留从假设 30 天变 60 天 | 同速率逻辑原始权威记录约 98.88 GiB | 授权查询、索引/备份及清理规则怎样变？ |
| 仅 broker E9 保留从 24h 变 48h | 原始事件约 0.824→1.648 GiB | 是否只解决 25h 离线个案，回放/权限仍如何保证？ |
不要把“连接翻倍”行的 40 入站/s 与“群扩大”行的 500 人再相乘，除非业务明确要求二者同时发生；那将是第六个新的组合情景。即使只改变一个主要变量，真实工作量也可能含高峰、在线率和重试，需用数据分布替代永远恒定的平均值。容量预测还要写增长来源、观察周期和置信程度，不能用线性外推掩盖突然上线的大群功能。Google SRE：有机/活动增长与容量
六、成本包括资源、冗余、复杂度和错误后果
没有价格表也能先把成本归属写清：网关 CPU/连接内存/TLS/网络出口；权威 DB 写入、索引、WAL、历史读取、副本、备份与恢复演练；broker 事件/副本/保留与积压；指标、日志、值班和变更维护时间。报价须以后续具体环境、保留/复制系数与供应方信息再核实，本章不报货币数或推荐购买某服务。Google SRE 的风险/成本讨论强调，更多冗余与更高可靠性带来资源和工程机会成本，但用户损害同样有代价。Google SRE：Embracing Risk
| 候选方案 | 可能降低哪种压力 | 新成本/风险 | 还需哪份证据 |
|---|---|---|---|
| 增加一个网关实例 | 网关连接、CPU 或设备任务分摊 | 实例/网络/调度成本；共享 DB 可能仍是瓶颈 | 同群热点、N−1 连接迁移和共享依赖压测 |
| 合并冗余的设备派生工作 | 重复编码/通知、设备任务数 | 可能漏掉应处理的设备；去重身份/顺序更复杂 | 目标设备确认、断线补拉、权限与回归用例 |
| E9 事件保留 24→48h | 某些 25h 离线时的 broker 回放可用性 | broker 原始字节约翻倍，回放/运维责任增加 | 真正的离线分布、broker 重放和权威 DB 补拉对照 |
| 增强权威历史读取/索引 | 长离线与热点查询时延 | 索引写放大、存储、迁移与维护成本 | 查询计划、页/池等待、备份和授权回归 |
有些成本优化不能做：不能为了减少 DB 字节就提前删掉已承诺保留的历史，不能因 broker 便宜就用它代替权威记录，不能为了减少通知数把应送达的设备静默漏掉。先写合同与可恢复性，再计算单位成本和残余风险。Google SRE：Data Integrity · 10.12 维护性评估
七、交一份可被试验推翻的决策书
最终建议可以是“暂不购买，先补取证”，但必须具体可审：业务场景/确认点 → 当前与增长假设 → 每项算式及单位 → 哪个资源先紧 → 两三个候选方案与成本/风险 → 隔离实验 → 停止/回退门 → 决策负责人和复核时间。若峰值或保留要求尚未获批，标注待定；若 100/s 单实例能力尚无实测，不能写“已具备”。11.07 实验包 · 10.11 ADR 与协作
验证要分别覆盖连接保持、活跃消息、50/500 人热点群、每人设备数、历史查询、25 小时离线、有界积压和 N−1 节点失效。开环负载须核对计划/实际/未启动请求，长稳需检查内存和 backlog 不持续爬升；恢复时要确认有权权威历史和设备 ACK，不以“CPU 降了”替代用户结果。11.08 的纸上 SLO 只是候选，不能拿未批准比例宣布发布门通过。11.07 开闭环/恢复 · 11.08 指标版本
固定 openimsdk/open-im-server 提交 f6411a8a1a31d3df36f4c2b3ad28481a94141e1f 的 send.go 选定分支调用 MsgToMQ 后返回；另一 Mongo 消费路径调用 BatchInsertChat2DB。两段只支持发送返回与消费落库分属异步阶段，不能推出上游真实连接数、消息吞吐、数据库保留、broker 保留、实例容量或云成本。OpenIM 阅读地图
八、22 道分层练习：提交卷末容量决策表
先独立计算，再展开反馈；所有结果只在本章给定条件下成立。
基础 1–8：把单位说准
1. 一万在线连接等于一万条消息/秒吗？
不等于。需活跃比和每活跃连接的发送率。
2. 10,000 连接、2% 活跃，活跃连接多少？
10,000×0.02=200 条。
3. 200 活跃连接各发 0.1 条/s，入站多少？
200×0.1=20 条/秒。
4. 每条恰好 50 目标成员、每人 2 设备且无过滤，设备任务多少？
20×50×2=2,000 项/秒，不是 2,000 条新权威消息。
5. 2,000 项/s 每项假设 512 B，纯载荷约多少 MiB/s？
2,000×512÷1,048,576≈0.977 MiB/s，未计协议/重试。
6. 每连接 32 KiB、10,000 连接的连接态分量多少？
10,000×32÷1024=312.5 MiB，不是进程总 RSS。
7. 当前 S2 的 200 能证明未来 B 设备已收到吗？
不能。它只代表本进程内存受理。
8. 本章 30 天权威历史保留已成为现行合同吗？
没有。它是未来业务若批准时的容量情景。
计算 9–16：历史、事件和故障余量
9. 20 条/s 一天有多少条权威消息？
20×86,400=1,728,000 条/天。
10. 每条原始逻辑记录 1 KiB，一天约多少 GiB？
1,728,000÷1,048,576≈1.648 GiB，不含索引/副本/备份。
11. 同速率、获批保留 30 天，原始记录约多少 GiB？
1.648×30≈49.44 GiB，不是账单总存储。
12. 每入站一条 E9、每事件 512 B、保留 24h，原始事件约多少 GiB？
20×86,400×512÷1,073,741,824≈0.824 GiB。
13. 相同事件流保留改 48h，原始量约多少？
约 1.648 GiB，只是 24h 量两倍，不含 broker 副本与其他事件。
14. 每实例纸上 100 入站/s、三实例失一，名义能力与余量多少？
剩 2×100=200/s；对另设目标峰值 150/s，名义余量 50/s。
15. 若只有两实例，失一后能守 150/s 吗？
不能，剩 100/s，小于目标。
16. 原 20 入站/s、目标群 50→500 人，设备任务怎样变？
在其余条件不变时从 2,000 变 20×500×2=20,000 项/s，十倍。
决策 17–22：比较方案和业务风险
17. 连接数翻倍且活跃比/发送率不变，连接态与入站各多少？
连接态约 625 MiB，入站约 40 条/s；这是单独情景，不与群 500 人自动叠加。
18. B 离线 25h、教学 broker 保留 24h，如何恢复 m-9？
从有权权威 DB 历史按 seq9 缺口补；增加 broker 保留不能替代这条路径。
19. 增加网关实例一定解除 DB 瓶颈吗？
不一定。共享 DB、broker 或热点可能仍先饱和，需同负载验证。
20. 为省钱能删掉已承诺保留的权威历史吗？
不能。先守业务保留/授权与恢复合同，再讨论索引、分层和成本。
21. 固定 OpenIM 两处源码能给真实容量和云账单吗？
不能。它们只提示选定发送与 Mongo 消费的异步边界。
22. 一份可审容量与成本决策书至少交什么？
业务确认点、工作负载/增长、单位算式、瓶颈/共享依赖、N−1、方案成本/风险、实验证据缺口、停止/回退门与复核负责人。
本章完成标准与后续路径
能手算 20 入站/s、2,000 设备任务/s、连接态 312.5 MiB、纸上权威/事件原始保留量，区分 N−1 名义余量与真实热点风险；并为加网关、削冗余派生或延长 E9 保留写出成本、业务副作用与验证门，才算完成第十一卷。所有数值仍须在学习者的隔离实现和获批业务要求下重新测量。接下来按学习路线先回补 03.11–03.12 的隔离与资源故障，再进入第十二卷的平台运行前置。