We have the queue publisher and subscriber, the subscriber is going with multi-threads.

The problem is the queue has been increasing too quickly, the consumers can not follow the increment speed, as you see:

root@ubuntu:~# for i in `seq 1 10`;do rabbitmqctl list_queues -p /actionlog;sleep 1;done
Listing queues …
queue_storm_actionlog 12665787
Listing queues …
queue_storm_actionlog 12670873
Listing queues …
queue_storm_actionlog 12667975
Listing queues …
queue_storm_actionlog 12672645
After one day or about, the queue size can be more than 20 millions, thus RabbitMQ becomes high load and the consuming process is very slow.


Increase # of throughput of consumers or reduce publishing rate. If consumers cannot
catch up, hardware upgrades will only offset the moment when systems starts running
low on resources.

If messages can be lost, 3.1 introduces a new feature, queue length limit:

Further to the suggestion of imposing a maximum queue length, you could
also consider imposing a maximum message age and instruct the broker to
discard messages that become stale:


  • 增加消费者的处理能力,或减少发布频率
  • 单纯升级硬件不是办法,只能起到一时的作用
  • 考虑使用队列最大长度限制,RabbitMQ 3.1支持
  • 给消息设置年龄,超时就丢弃