我们正在开发一个基于storm的物联网信号处理平台，并考虑到横向可扩展性。该平台旨在通过应用一系列信号处理算法，同时处理多个信号（从mqtt主题收集）。到目前为止，我们的解决方案包括，如图所示：
mqtt服务器，主题名称包括信号的标识符（例如，“patient/1”、“patient/2”、“patient/n”）。
一个mqtt喷口，它订阅了其名称为
匹配模式“patient/+”（因此，接收所有信号的值和每个信号的标识符）。我们在用这个
方法，因为我们不知道有多少信号可以在某个点接收，我们不希望和不同的喷口为每一个可能的
信号！
几个链式螺栓，每个信号处理步骤一个
（算法）。
我们解决方案的初步测试效果很好。通过建立对喷口的并行性提示，我们能够注意到storm是如何将负载分布在多台机器上的，从而提高了整个系统的吞吐量。然而，根据我们的理解，通过这种配置，我们有一个单一的故障点：mqtt-spout，它现在将是一个运行在storm的一个节点中的示例。我们知道（因为我们尝试过）将并行性提示启用到这样的喷口不是一个好主意，因为它会产生一种效果，即创建同一主题的多个mqtt订户，从而在处理螺栓上传播同一信号的多个副本。
所以，我们现在的问题是：
你认为我们目前的方法有什么缺点吗，主要是考虑到我们的可伸缩性需求？
给定storm的聚类模型，有一个mqtt喷口（没有并行性提示）可以被认为是一个单点故障(例如，如果运行它的计算机出现故障，或者storm会保证它在集群的其他计算机中恢复吗？
考虑到我们的目标是一个可扩展的体系结构，我们考虑将emq或activemq等“集群化”mqtt服务器作为信号的入口点。然而，我们认为我们的单个mqtt喷口在某个时候可能会成为瓶颈。您能给我们一些关于如何扩展从mqtt主题读取数据所需的资源的建议吗，以避免冗余值读取的问题？
谨致问候！