我们有一个现有的设置，上游系统在Message Queue上向我们发送消息，我们处理这些消息。内容是xml，我们只是解组。这个解组步骤之后是写入db（将相关值放到上面）相关专栏）。 该系统设置为与更多上游系统连接，我们的体积将增加到每天40毫米的峰值。
我们当前的处理方式是在队列上有监听器，然后有生产者和消费者的多个线程进行解组和后续的db编写。
我的问题：此过程是否适合Storm用例场景？ 我的意思是MQ可以作为我的鲸鱼喷水器，我有2个螺栓可以解组，然后这就成了下一个写入db的螺栓的喷口吗？
如果是，我可以获得什么好处？是繁琐的多线程生产者/工作者代码模式的再见。 如果它像上面那样简单，那么在哪里/为什么人们想要采用传统的多线程方法来生产者/消费者场景 我的观点是，与传统方法相比，Storm开始闪耀的数据量/频率。
PS：我对此非常陌生，试图弄清楚这一点，并想确定思路是否正确此致 CVM
答案 0 :(得分：3)
这种情况肯定适合风暴拓扑。喷嘴可以从MQ拉出，螺栓可以处理解组和后续处理。
与传统多线程模式相比，主要优点是能够在负载增加时添加更多工作节点。传统的生产者消费模式并不容易。
特定数据卷数是一个非常广泛的问题，因为它取决于许多因素，如硬件等。