RabbitMQ重新排队

作者: 那月静好
发布时间: 2025-01-02 06:45:22 (3天前)
转自：

3 条回复

0#
回复此人
谦成 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 谢谢@Olivier。同 <code> channel.basic_qos(prefetch_count=1) </code> 我得到了记录的行为： <BLOCKQUOTE> INFO：root：使用路由键'foobar'生成消息'a' 信息：root：使用路由键'foobar'生成消息'b' INFO：root：使用路由键'foobar'生成消息'c' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' 信息：root：来自队列'foobar'的消息'a' </BLOCKQUOTE> </DIV>

编辑
1#
回复此人
别烦我 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 您遇到的行为很可能是由于预取行为。 由于您没有指定所需的服务质量，我相信（会更好地了解一个知识渊博的来源来证实这一点吗？）预取由服务器决定，并且可能会相当高。 我们的想法是，对于性能问题，客户端可以获得多条消息，这在大多数情况下都是有利的： <UL> <LI> 如果在消费者方面存在多线程，他可能可以并行处理多个消息处理，因此在任何给定时间内都会有多个消息未被处理 </LI> <LI> 为了在“快乐”的情况下允许更多流体处理，客户端可以确认消息块，让服务器知道最多给定消息，消费者收到的所有消息都被激活，当我们有大的情况时它减少了开销需要很少处理的消息量 </LI> </UL> 如果查看下面的文档链接，它们将说明如何控制行为。 有关这些要点的其他信息，请访问： <UL> <LI> <a href="https://www.rabbitmq.com/confirms.html#channel-qos-prefetch" rel="nofollow noreferrer"> RabbitMQ - 确认 - 预取 </A> </LI> <LI> <a href="https://pika.readthedocs.io/en/stable/modules/channel.html" rel="nofollow noreferrer"> 皮卡读了文档 - 频道 </A> </LI> </UL> </DIV>

编辑

登录后才能参与评论