消息队列：哪一个是最佳方案？

Question

我写了一个网络抓取工具。

抓取工具有两个步骤：

1. 获取HTML页面
2. 然后解析页面

我想使用消息队列来提高性能和吞吐量。

---

我认为有两种情况：

方案1：

    structure: 
    urlProducer -> queue1 -> urlConsumer -> queue2 -> parserConsumer

urlProducer：获取目标网址并将其添加到queue1

urlConsumer：根据工作信息，获取html页面并将其添加到queue2

parserConsumer：根据工作信息，解析页面

方案2：

    structure:
    urlProducer -> queue1 -> urlConsumer
    parserProducer-> queue2 -> parserConsumer

urlProducer：获取目标网址并将其添加到queue1

urlConsumer：根据工作信息，获取html页面并将其写入db

parserProducer：从db获取html页面并将其添加到queue2

parserConsumer：根据工作信息，解析页面

---

每个结构中都有多个生产者或消费者。

scenariop喜欢链接电话。发生错误时，很难找到问题所在。

scenario2将queue1和queue2解耦。发生错误时，很容易找到问题所在。

我不确定这个概念是否正确。

哪一个是最佳方案？或其他情况？

感谢〜

Answer 1

我认为场景1是您的最佳选择，因为您不必监控数据库，这可能会减慢速度。不确定你打算用它来实现这个目标，但我可以通过几种不同的方式看到它：

1. 使用Kafka并按照您指定的方式布置消费者。
2. 使用storm而不依赖于消息队列。基本上，您正在进行流处理。

还有其他方法可以做到这一点（Web服务，嵌入式队列，如ZeroMQ，其他经纪人等），但是既然你提到了吞吐量，那么这两种方案可以为你提供良好的吞吐量。

Answer 2

在我看来，如果你想使用一个简单的消息传递系统，那么第二种情况将是处理这个问题的更好方法。您实现的三个关键任务是获取链接，从链接中获取页面并解析它们以获取所需信息。我们需要记住，执行这些操作的速率取决于所提取页面的大小。你最好有一个中间存储，以避免堵塞排队系统。

话虽如此，我同意@ blockcipher在此主题上的答案，使用Storm Clusters而不是简单的排队机制。风暴工作者节点还可以为您定义流量控制方法，以便以平均速率改变不同流的流量。在这种情况下，第一种情况会更有益。因此，您的选择取决于您计划用于实施解决方案的内容。