消费RabbitMQ时的注意事项，如何禁止大量的消息涌到Consumer，保证线程安全

最新推荐文章于 2026-06-24 09:16:03 发布

转载最新推荐文章于 2026-06-24 09:16:03 发布 · 3.6k 阅读

收录于

RabbitMQ

当前文章被收录于：

RabbitMQ

1 篇文章 0 人学习

订阅专栏查看详情

当前文章被以下社区和专栏收录：

本文探讨了RabbitMQ中使用RetrievingMessagesBySubscription方式导致的消息积压问题，并提出了解决方案。通过设置Channel的QoS参数，限制了客户端接收消息的数量，确保每条消息被确认后才接收下一条，有效避免了Consumer崩溃导致的消息重复消费。

按照官网提供的订阅型写法（ Retrieving Messages By Subscription ("push API")）我发现，RabbitMQ服务器会在短时间内发送大量的消息给Consumer，然后，如果你没有来得及Ack的话，那么服务端会积压大量的UnAcked消息，而Consumer如果来不急处理也会处于假死（也可能引起程序崩溃）。

仅有两个Channel，结果积压了大量的UnAcked消息。

这明显是与我们的目的不一致，我们不能保证Consumer一定会急时快速的处理消息。所以这种方式带来的后果就是Consmer崩溃后，UnAcked消息又ReQueue，这肯定会消耗MQ的宝贵资源。

我试图在官网上找到一种方法，让每条消息明确的Ack后再接受下一条。但是好没有。好在在 gitbooks.io/rabbitmq-quick/ 这儿找到了，通过设置Channel的QOS即可

  
        var 
        channel = Connect.CreateModel();
       
        channel.BasicQos(0,1,
        false
        ); 
        //RabbitMQ客户端接受消息最大数量