消费RabbitMQ时的注意事项,如何禁止大量的消息涌到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即可
1 2 | var channel = Connect.CreateModel(); channel.BasicQos(0,1, false ); //RabbitMQ客户端接受消息最大数量 |
设置后的结果:
在开启4个Consumer的情况下,每条消息处理要耗时2秒。然后问题解决了。Unacked的消息只有4个。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!