19 容量估算与扩展¶
难度：高级｜前置：IoT 前八单元｜目标：不会虚构百万经验，但能做可信容量设计
从估算开始¶
十万设备，30 秒一条心跳：
但容量不能只看平均值。假设网络恢复后 20% 设备在 10 秒内重连：
同时还可能补发遥测和订阅，形成突发。
分层估算¶
连接层¶
- 同时在线连接；
- 新建连接/秒；
- TLS 握手 CPU；
- 文件描述符；
- 心跳和连接状态内存。
消息层¶
- 平均和峰值消息/秒；
- 单条大小；
- Topic 匹配；
- QoS 确认流量；
- 规则引擎放大倍数。
存储层¶
- 每日记录数；
- 原始与索引大小；
- 写入批次；
- 查询并发；
- 保留和聚合。
下游¶
- 告警通知；
- WebSocket 推送；
- 外部 API；
- Agent/AI 分析。
横向扩展的前提¶
无状态 API 容易扩展；有状态连接和任务需要决定状态在哪里：
- Broker 集群管理连接；
- 状态服务按 device_id 分片；
- Redis/数据库保存共享状态；
- MQ 分区保持局部顺序；
- Worker 可重新领取任务。
热点¶
平均分片并不保证无热点：
- 一个大租户；
- 一个被大量订阅的 Topic；
- 一个全局在线 Set；
- 一个超大 ZSet；
- 同一时间批量 OTA。
分片键需要结合访问模式，而不只是取模。
压测¶
至少测试：
- 稳态消息；
- 突发重连；
- 下游变慢；
- Redis/数据库延迟；
- 消费者重启；
- 重复和乱序；
- 长时间运行后的内存。
面试诚实边界¶
我实际维护规模没有达到百万连接，但会从连接、消息、存储和下游四层估算，并重点测试批量重连而不是只看平均吞吐。状态服务按设备或租户分片，关键瓶颈用指标和压测验证。
完成标准¶
- 能计算十万设备平均和突发流量
- 能列出四层容量指标
- 能识别至少四个热点
- 能设计一份故障压测清单
下一单元：从 IoT 到 AIoT