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