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消费端的限流策略
