EMQX

EMQX是围绕 MQTT 设备连接、主题路由和实时数据集成构建的消息平台，常用于智能硬件、工业设备与车联网。评估它不能只看同时在线连接数：设备如何证明身份、能访问哪些 Topic、断网后消息怎样恢复，以及外部系统失败时如何补偿，才共同决定链路是否可靠。

给每台设备独立且可撤销的身份

不要让整批设备共用一个密码。按生产批次或单设备签发凭据，建立吊销和轮换流程，公网监听器启用 TLS 并限制连接速率。EMQX 支持内置数据库、JWT、HTTP 及多种外部数据源等认证方式；官方文档还提供按顺序评估的认证链，但具体能力应以当前版本和监听器类型验证。

Topic 权限同时约束发布与订阅

设备身份通过认证后，还要分别限定可发布和可订阅的主题，例如只允许写入自己的遥测路径、读取属于自己的命令路径。通配符规则应从最小范围开始，用越权设备测试跨租户订阅、系统主题和保留消息，避免仅在正常客户端上验收。

先定义消息语义再选择 QoS

根据温度遥测、告警、控制命令等业务分别决定 QoS、会话过期、遗嘱、保留消息和离线队列。更高 QoS 不等于业务只处理一次，客户端重连、桥接重试和消费者故障仍可能产生重复；消息应携带事件编号与时间，业务端实现去重或幂等。

用一条温度消息检查端到端语义

设备向 devices/{id}/telemetry 发布包含事件编号、采集时间、温度和固件版本的消息。Broker 验证设备只能写自己的主题，规则引擎筛出异常温度并写入告警流，普通遥测进入时序存储。随后主动制造重发、乱序、设备断线和数据库不可用，观察消息是否重复、积压或丢弃。

规则与桥接只是数据路径的一段

规则引擎可用类 SQL 从 MQTT 消息或客户端事件中筛选字段、转换载荷，并将结果重新发布或送往 Kafka、数据库等外部系统。为每条规则记录输入 Topic、输出目标和失败策略，监控积压、丢弃与重试。消息被 Broker 接收或桥接成功，都不等于最终业务事务完成。

容量测试要模拟真实断线和峰值

用接近生产的连接增长速度、订阅数量、载荷大小和消息峰值测试端到端延迟、内存、存储与网络，再演练节点滚动升级、运营商抖动和下游停机。开源版、企业版与 EMQX Cloud 的功能、许可、服务和计费不同，选型结论必须绑定实际交付形态与版本。