RabbitMQ消费端的限流策略

假设一个场景，由于我们的消费端突然全部不可用了，导致rabbitMQ服务器上有上万条未处理的消息，这时候如果没做任何现在，随便开启一个消费端客户端，就会导致巨量的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多的数据，就会导致消费端变得巨卡，有可能直接崩溃不可用了。所以在实际生产中，限流保护是很重要的。

rabbitMQ提供了一种QOS(服务质量保证)功能，即在非自动确认消息的前提下，如果一定数目的消息(通过基于consume或者channel设置QOS的值)未被确认前，不进行消费新的消息。关键代码就是在声明消费者代码里面的 void basicQos(unit prefetchSize , ushort prefetchCount, bool global )

prefetchSize：0

prefetchCount：会告诉RabbitMQ不要同时给一个消费者推送多于N个消息，即一旦有N个消息还没有ack，则该consumer将block掉，直到有消息ack

global：true\false 是否将上面设置应用于channel，简单点说，就是上面限制是channel级别的还是consumer级别

备注：prefetchSize 和global这两项，rabbitmq没有实现，暂且不研究。特别注意一点，prefetchCount在no_ask=false的情况下才生效，即在自动应答的情况下这两个值是不生效的。

代码演示： 代码地址：    https://github.com/hmilyos/rabbitmq-api-demo

生产端代码基本没变化，改了exchange和routingKey而已

生产端代码

消费端代码需要修改一下autoAck设置为 false和增加channel.basicQos(0, 1, false);

消费端改动的重点代码

完整的消费端代码如下

消费端完整代码

自定义消费者的没改动

自定义消费者代码

然后启动消费端，上管控台查看test_qos_exchange和test_qos_queue是否生成了

确认test_qos_exchange上绑定了test_qos_queue

启动生产端发送5条消息

发现消费端只消费了一条消息

从管控台上也看到总共五条消息，有4条等待着，一条消费了但是没有ack回去

修改自定义消费者里面的代码，如下所示

，修改后的

重启消费端，看到消费端就按照一条一条消费，并且ACK回去了

如上所示就是简单的RabbitMQ消费端的限流策略