运营商网络恢复、区域故障切换，或证书发布让设备集中重启时，原本稳定的设备群可能在数秒内形成重连风暴。这时产生的负载不是普通发布流量：每个客户端都可能重新执行 TLS 协商、认证、会话恢复、订阅、排队消息投递和应用层追赶。
容量规划必须先定义恢复目标。如果 60,000 台设备需要在 10 分钟内恢复，系统至少要持续完成每秒 100 次成功恢复，而且这还没有计入重试、无效凭据和不均匀的网络恢复节奏。
建模恢复工作，而不是空闲连接数
对每类设备至少采集：
- 当前与峰值连接数；
- 每秒连接和断开次数；
- 两个方向的消息速率；
- 平均与 P95 载荷大小；
- QoS 分布和 Retained Message 数量；
- 每个客户端的订阅数与通配符范围；
- 预期离线时长和排队策略；
- 日常峰值与事件驱动的突发模式。
先计算一个最低值：
每秒所需成功恢复数 = 离线客户端数 / 恢复窗口秒数
再加上每次恢复背后的工作：TLS 握手、身份查询、订阅恢复、排队 QoS 消息、Retained Message，以及设备恢复后的第一波遥测。区域网络恢复后的集中重连，通常会产生比日常发布更高的认证和订阅恢复压力。
预发布测试必须回放真实客户端行为。只保持大量空闲 Socket，无法代表证书握手、订阅恢复、排队消息和下游处理。
选择能够独立恢复的设备批次
当设备群在以下方面存在显著差异时，应拆分 Broker 运行环境：
- 合规或数据驻留要求；
- 可用性目标；
- 发布节奏；
- 流量特征；
- 运维负责人；
- 客户隔离承诺。
环境、区域、主要租户组或产品线通常是实用边界。不要在缺少运维理由时为每个小客户创建 Broker，过度碎片化会增加策略、监控和升级成本。
RunMQTT 使用隔离的 Broker 实例、策略模板和设备身份，让容量与权限决策始终附着在对应工作负载上。
让订阅与主题具备分区能力
可扩展主题树需要显式表达所有权和路由维度：
prod/{region}/{tenant}/{site}/{deviceId}/{channel}
不要放入频繁变化的标签，应使用稳定 ID，并避免把高基数字段塞进主题。prod/# 这类宽订阅会逐渐变成昂贵的运维和安全依赖；分析链路应通过职责明确的消费者和有限前缀接入。
通配符与权限的取舍见 MQTT 主题设计指南。
避免认证成为关键瓶颈
手工创建设备无法支撑企业规模。制造或注册流程应统一完成：
- 创建设备记录；
- 分配经过评审的策略模板；
- 通过受保护渠道交付凭据；
- 记录激活状态；
- 轮换或吊销凭据；
- 硬件退役时同步删除身份。
尽量保持一台设备一个身份。如果网关代表下游设备，需要记录这一信任边界，并将权限限制在指定站点或子设备前缀。
把客户端退避纳入容量设计
所有客户端都必须使用带抖动的指数退避。凭据和固件按批次发布，避免一个错误迫使整个设备群同时重连。
容量测试需包含冷启动、区域网络恢复、过期凭据、持久会话恢复、有限离线队列，以及慢速或不可用的下游消费者。通过消息过期和队列上限保证恢复期间处理的工作仍有价值。相比让历史积压阻塞当前状态，丢弃过期遥测通常更安全。
把区域切换当作一次重连事件
多区域架构需要明确业务目标：系统需要灾难恢复、Active-Active 客户端分布、数据复制，还是三者兼具。
设备需要确定性的健康端点发现方式。只复制切换后真正需要的状态，并定义 Retain、指令和重复事件跨区域时的行为。演练必须包含真实 DNS、证书、客户端退避和下游依赖。
端到端衡量恢复预算
除 Broker 健康外，还要监控连接成功率、认证延迟、连接抖动、会话恢复、发布到消费延迟、授权拒绝、队列深度、过期消息、载荷分布、心跳新鲜度和下游延迟。
围绕产品结果设置恢复目标，例如“95% 的受影响设备在 10 分钟内恢复最新遥测，且不会执行超过 60 秒的陈旧指令”。Broker 可用性保持正常时，认证仍可能饱和，分析消费者也可能已经落后数小时。
测试完整时间线，而不是一个峰值数字
把负载测试写成时间线：稳定流量、突然断开、故障持续、网络恢复、会话恢复，以及回到稳定延迟预算。记录最大成功连接速率、失败次数、P95 认证延迟、队列年龄、下游积压和总恢复时间。
固件、证书、策略和端点变更都可能制造同样的重连模式，因此都应作为正式发布处理。使用金丝雀批次、明确回滚标准，并安排负责人持续观察恢复指标。
先使用本地运行的 MQTT 设备群容量与成本计算器，明确连接数、消息单位、扇出和重连假设。选择运行模式前，可以比较托管与自建 MQTT Broker。如果重点是隔离、设备身份和可预测的设备群运维，可继续查看 RunMQTT 定价。