我正在将RabbitMQ架构到我们的解决方案中，我很好奇如何有效地处理和确认消息，同时仍然在消费者代码中执行“真实的”工作，时间范围从5到10秒不等。（比samples更深入的工作）。
上面是我打算处理的一个例子。我的twitter.tweet_cmd_q队列中的一条消息，它具有消息体中所需的所有参数，供消费者发出实际的Twitter API请求，并将这些结果保存到DB中。
但是，我在这里遇到了两个问题：
1.我每分钟要处理数千条记录-我不可能花5-10秒的时间来确认这条消息。消费者代码在确认消息之前处理所有需要的工作是“正常的”吗？（也就是说，我可以看到确认消息，并将实际工作扔到另一个线程中进行处理。- 尽管这将需要它自己的“线程”管理形式，以便系统确实承受太多的负载）。
1.在这种涉及查询数据并将其保存到DB的情况下，RPC calls对我有什么好处吗？
1.处理这种可伸缩性的最好方法是创建更多的工作示例来进行循环调度吗？
2条答案
按热度按时间2mbi3lxu1#
1.是的，消费者代码在确认消息之前对消息做它需要做的一切是正常的。这就是管理消息对其他工作人员可见性的方法。
1.不，保持简单，只是做你需要在工人做的。
1.某种程度上，它不是真正的循环调度，只是创建更多的工作者，并让他们订阅队列。每个worker都将轮询队列，查找消息并对其执行。
mv1qrgav2#
Rob的回答很棒，我只是想补充一下：
消费者代码在确认消息之前处理所有需要的工作是“正常的”吗？
如果您在处理消息之前确认消息，并且您的使用者崩溃或没有完成任务，则该消息将丢失。这就是只有当你的工作完成时才确认的主要原因。您可以在这里找到相关文档：https://www.rabbitmq.com/confirms.html