我们正在开发一个基于STORM的物联网信号处理平台，并考虑了水平可扩展性。该平台旨在同时处理多个信号(从 MQTT 主题收集)，方法是对它们应用一系列信号处理算法。到目前为止，我们的解决方案包括，如下图所示：
-
MQTT 服务器，其主题名称包含标识符 信号(例如，"患者/1"、"患者/2"、"..."、"患者/N"。
-
一个 MQTT 喷口，它订阅了名称与
模式 'patient/+' 匹配的所有主题(因此，接收所有 信号和每个信号的标识符)。我们正在使用这种方法
，因为我们不知道在某些时候可以接收到多少信号 点，我们不希望每个可能的
信号都有不同的喷口！ -
几个链式螺栓，每个信号处理步骤
(算法)一个。
我们解决方案的初步测试效果很好。 通过建立喷口的并行提示，我们能够注意到 Storm 如何在多台机器上分配负载，从而提高整个系统的吞吐量。但是，根据我们的了解，使用此配置，我们有一个单点故障：MQTT 喷口，现在它将是在 Storm 的一个节点中运行的单个实例。我们知道，为这样的 Spout 启用并行提示不是一个好主意(因为我们尝试过)，因为它会为同一主题创建多个 MQTT 订阅者，从而在处理 Bolts 上传播同一信号的多个副本。
因此，我们此时的问题是：
-
你认为我们目前的方法是否有任何缺点，主要是 考虑我们的可扩展性要求？
-
给定 Storm 的聚类模型，具有单个 MQTT 喷口 (没有并行提示)可以被视为单点 失败？(例如，如果运行的计算机出现故障)，或 暴风会保证它在集群的其他机器上恢复吗？
-
鉴于我们的目标是可扩展的架构，我们是 将"可集群化"的 MQTT 服务器(如 EMQ 或 ActiveMQ)视为 信号的入口点。但是，我们认为我们的单曲 MQTT喷口可能会在某个时候成为瓶颈。你能给我们吗 有关如何扩展读取数据所需的资源的一些建议 从 MQTT 主题，避免冗余值问题 读数？
亲切问候！
您可能想查看称为MQTT共享订阅的东西。
这是 MQTTv5.0 规范中一个新的可选功能(但在许多实现 MQTT v3.1 的代理中有一些专有实现，例如 IBM MessageSight 和 HiveMQ)。这允许多个订阅者订阅同一主题，并使消息在它们之间负载平衡，而不是所有消息传递给所有订阅者。
我不知道有任何(生产)代理实施MQTT v5.0(2018年4月)。