我们有一个现有的设置，上游系统通过消息队列向我们发送消息，我们处理这些消息。内容是xml，我们只需解组。这个解组步骤之后是对db的写入（将相关值放入相关列）。该系统将与更多的上游系统连接，我们的流量将增加到每天40毫米的峰值。
我们当前的处理方式是在队列上有侦听器，然后有多个生产者和消费者线程来执行解组和随后的db写入。
我的问题是：这个过程是否适合storm用例场景？我的意思是mq可以是我的喷口，我有两个螺栓，一个要解组，然后这就变成了下一个螺栓的喷口，下一个螺栓会写入db？
如果是，我能得到什么好处？这是一个告别繁琐的多线程生产者/工作者模式的代码。如果它像上面那样简单，那么在哪里/为什么要诉诸传统的多线程方法来处理生产者/消费者场景呢？我的观点是，与传统方法相比，storm开始出现的数据量/频率是多少。
附言：我对这一点很陌生，我想了解一下这个问题，看看思路是否正确
你好，cvm
1条答案
按热度按时间tf7tbtn21#
当然，这个场景可以适合风暴拓扑。喷口可以从mq中拉出，螺栓可以处理拆封和后续处理。
与传统的多线程模式相比，它的主要优点是能够随着负载的增加添加更多的工作节点。这对于传统的生产者-消费者模式来说并不容易。
特定数据量是一个非常广泛的问题，因为它取决于大量的因素，如硬件等。