因为原来使用了MQ作为rpc机制，随着客户交易量越来越大，很多服务器推送行情的压力很大，最近打算重写为批量模式，又重新看了下qos和prefetch设置的作用以确定优化的具体细节。
消费者在开启acknowledge的情况下，对接收到的消息可以根据业务的需要异步对消息进行确认。
然而在实际使用过程中，由于消费者自身处理能力有限，从rabbitmq获取一定数量的消息后，希望rabbitmq不再将队列中的消息推送过来，当对消息处理完后（即对消息进行了ack，并且有能力处理更多的消息）再接收来自队列的消息。在这种场景下，我们可以通过设置basic.qos信令中的prefetch_count来达到这种效果。
1. rabbitmq对basic.qos信令的处理
首先，basic.qos是针对channel进行设置的，也就是说只有在channel建立之后才能发送basic.qos信令。
在rabbitmq的实现中，每个channel都对应会有一个rabbit_limiter进程，当收到basic.qos信令后，在rabbit_limiter进程中记录信令中prefetch_count的值，同时记录的还有该channel未ack的消息个数。
注：其实basic.qos里还有另外两个参数可进行设置，prefetch_size和global，但是RabbitMQ没有实现prefetch_size，并在3.3.0版本中对global这个参数的含义进行了重新定义，即glotal=true时表示在当前channel上所有的consumer都生效，否则只对设置了之后新建的consumer生效
| global | Meaning of prefetch_count in AMQP 0-9-1 | Meaning of prefetch_count in RabbitMQ |
|---|---|---|
| false | shared across all consumers on the channel | applied separately to each new consumer on the channel |
| true | shared across all consumers on the connection | shared across all consumers on the channel |
一个 queue 中消息最大保存量可以在声明
queue 的时候通过设置 x-max-length 参数为非负整数进行指定。Queue 长度的选取需要考量 就绪消息量、被忽略的未确认消息量，以及消息大小。当
queue 中的消息量达到了设定的上限时，为了给新消息腾出空间，将会从该 queue 用于保存消息的队列的前端将“老”消息丢弃或者 dead-lettered 。
其实从这样来看的话，如果MQ和应用服务器之间的网络延时比较大并且应用服务器处理消息的逻辑比较慢，这时候优化一些prefetch count是有意义的具体可以设置1、5、10、30、50、100、1000看consumer的utilization，越接近100%越佳，反之延时很低其作用就没这么大了。
一条消息从客户端到MQ中一般经过如下环节：
Network
↓
Connection process - AMQP parsing, channel multiplexing
↓
Channel process - routing, security, coordination
↓
Queue process - in-memory messages, persistent queue indexing
↓
Message store - message persistence
每个环节都可能会成为瓶颈。
具体参见http://www.rabbitmq.com/consumer-prefetch.html。