简要回答

此估算器将六项工作负载假设转化为最低代理测试范围。它将并发连接、发布吞吐量、路由投递、持久会话、重连压力和离线积压作为独立需求分别呈现。这种分离很重要：代理在稳态发布时可能看起来健康，但在数千个客户端在故障后恢复会话时仍可能崩溃。

它不是厂商选型计算器。代理实现在路由索引、会话存储、集群、认证、持久化和运行限制方面各不相同。使用输出来设计一个类似于你系统的基准测试，然后测量你打算运行的代理和基础设施。

输入参数

  • 并发连接数是峰值已连接客户端数，而非注册设备总数。包括共享同一集群的网关、后端消费者和管理客户端。
  • 每秒消息数是所选工作点下的预期入站发布速率。
  • 每客户端平均订阅数提供简单的路由工作代理值。使用代表性客户端的观测平均值，而非策略允许的最大值。
  • 持久会话百分比是断开后会话状态得以保留的已连接客户端比例。
  • 故障后每秒重连数是认证、网络、代理和会话存储必须共同承受的恢复速率。
  • 离线积压消息数是等待符合条件的客户端的排队消息总量。它是计数而非字节，因为消息大小和存储开销必须单独测量。

估算方法

工具直接报告输入的连接和发布目标。持久会话估算为：

并发连接数 × 持久会话百分比

路由投递数是一个刻意简单的工作负载代理值：

每秒消息数 × max(1, 每客户端平均订阅数)

这不是 MQTT 扇出语义。一个订阅可能不匹配任何发布，而一个发布可能匹配多个共享或普通订阅。该数值为测试提供可复现的起点；在采购前应使用生产环境追踪或真实主题分布替换它。

重连和积压保持为独立目标，因为将它们合并为单一分数会隐藏你需要测试的确切恢复行为。

示例分析

假设一个服务预期 100,000 个并发客户端、每秒 5,000 次发布、每客户端 3 个订阅。60% 使用持久会话。故障恢复计划允许每秒 2,000 次重连，同时可能有 100 万条排队消息需要可控排空。

估算器返回：100,000 并发连接、每秒 5,000 次发布、作为路由代理值最高每秒 15,000 次路由投递、60,000 个持久会话、每秒 2,000 次认证和会话恢复、100 万条排队消息。一个有用的基准测试应先运行稳态工作负载，然后移除一个代理节点，通过真实身份服务恢复客户端，并在不违反实时消息延迟或恢复时间目标的前提下排空积压。

结果无法告诉你什么

估算器不预测 CPU、内存、磁盘、网络或节点数。它不建模载荷大小、留存消息、MQTT QoS 交换、共享订阅负载均衡、通配符复杂度、TLS 握手、授权延迟、存储复制或不均匀的客户端行为。它也无法确定安全的单节点连接上限。

至少分别测试四种条件：稳态、重连恢复、积压排空和节点故障。捕获延迟分布和恢复时间，而不仅仅依赖聚合吞吐量。在你自己的测量结果基础上应用代理厂商的支持限制，而非替代它们。

隐私与分享

计算完全在浏览器中完成。提交表单会将数值和选择参数存储在当前 URL 中，使场景可以重新打开或分享。这些值可能暴露设备规模，因此如果真实数字属于机密，请使用代表性数值。不上传任何参数或结果到 IoT 01。

复制生成 Markdown 摘要。JSON、CSV 和 Markdown 导出由浏览器本地生成文件。

常见问题

路由投递数是代理保证吗？

不是。它是基于平均订阅输入的透明测试代理值。主题匹配和消费者拓扑决定实际扇出。

注册设备数应等于并发连接数吗？

通常不等。使用测量或规划的峰值并发数，包括使用同一代理集群的非设备 MQTT 客户端。

应该预留多少余量？

没有通用百分比。余量应从故障测试、增长预测、部署提前期和团队承诺的恢复时间目标中推导。

相关指南

使用设计大规模设备重连将重连目标转化为退避、准入控制、会话恢复和恢复测试。