简要结论

设备规模并未超出平均容量；相关性恢复工作同时突破了多个独立的速率限制。

案例性质

这是一次复合故障模式评审，不是基准测试、客户事故，也不声称某个特定设备规模达到一百万台。slug 名称描述的是工程师常搜索的规模问题。本文不主张任何吞吐量、持续时间或恢复数据，因为这些数值取决于代理、认证、会话、订阅、负载、网络和下游架构。

背景与目标

某IoT平台正常承载大规模联网设备，延迟可接受。工程目标是：在区域性网络中断或平台事件导致大量客户端在相关时间窗口内重连时，保持安全、有界的恢复能力。

稳态容量看似充裕。平均连接变化率低，消息吞吐量低于规划上限，代理节点有余量。缺失的问题是：当恢复工作集中到达时系统如何表现。

约束条件

设备运行不同固件和重连算法。部分设备保留会话并期望接收排队消息。认证依赖证书校验和外部身份服务。连接状态写入数据库并被其他服务消费。蜂窝和站点网络以波次恢复而非均匀恢复。

设备无法瞬时更新到新的退避策略。产品语义不允许简单丢弃所有持久会话或离线消息。

原始方案

客户端在传输断开后立即重连，使用短的固定重试间隔。负载均衡器将TCP连接分散到各代理节点。代理恢复会话、订阅和飞行状态，然后下游服务记录在线状态变更。容量规划用平均消息速率乘以设备数并增加代理节点余量。

测试计划度量稳态连接和发布。它未建模TLS握手、证书校验、会话查找、订阅恢复、保留消息投递、排队消息、状态写入和消费者重启同时发生的情况。

问题出在哪里

相关性恢复同时产生多种工作负载。TLS和认证在普通MQTT流量稳定之前就消耗CPU和外部服务容量。会话恢复读取存储状态并重建订阅。客户端发布启动、状态和缓冲遥测数据。订阅者恢复并可能请求保留或排队数据。状态服务为大量主体先写入断开再写入重连。

增加代理节点可能将瓶颈转移到认证、负载均衡、DNS、会话存储或数据库。激进客户端在首次请求仍在处理时就超时重试，放大负载。平台可能保持在平均消息目标以下，但恢复延迟增长且队列变得陈旧。

决策

将恢复速率视为一等容量维度。在客户端合约中要求指数退避加随机抖动。在服务器端实施准入控制，使平台可预测地拒绝或延迟工作，而非同时压垮所有依赖。

分阶段恢复：建立并认证连接，恢复关键会话状态，恢复关键订阅，在配额下排空非紧急积压。定义哪些消息过期而非在业务价值消失后重放。

修订后的架构

区域端点和故障域限制相关性范围。负载均衡器和代理暴露连接尝试、握手、接受、拒绝和建立指标。认证服务有缓存和显式保护限值，同时不绕过吊销要求。

会话存储分区化且可观测。代理策略限制飞行工作、离线队列大小、过期时间和每个主体的速率。下游状态处理合并状态转换，并避免在连接路径上产生同步数据库依赖。

客户端使用随机退避、限制重试次数，并区分认证拒绝和临时不可用。关键设备行为在本地降级而非依赖即时云端重连。

取舍

较慢的准入延长了全设备上线时间，但保护了有用的部分服务和下游系统。队列过期可能丢弃数据，因此产品团队必须识别哪些数据可替代、哪些需要持久投递。区域隔离增加运营成本并使跨区域状态更复杂。

减少持久会话的使用可以降低恢复状态，但会改变离线行为，不能视为免费的基础设施优化。

待验证结果

要求的结果是在生产级测试下有界、可观测的恢复。团队应了解：接受的连接速率、被拒绝或延迟的工作、队列年龄、依赖饱和度、关键服务恢复时间和非关键积压排空时间。没有通用目标；每个产品从其运营需求定义目标。

测试应包含从未收到首次响应而重试的客户端，因为理想客户端可能隐藏生产网络将产生的放大效应。

可复用的经验

基准测试相关性故障而非仅测稳态。在客户端加抖动、在服务器加准入控制。分别度量认证、会话、订阅和下游写入。过期陈旧工作。用真实固件和网络波次演练恢复。

不应盲目照搬之处

不要从本复合案例中选择退避范围、队列限制或区域设计。不要为通过负载测试而禁用认证或证书校验。不要在定位实际瓶颈之前增加代理。也不要将“所有socket已连接”等同于服务恢复；应验证消息流和业务健康度。