参考：
/
/blog/2014/04/03/an-end-to-synchrony-performance-improvements-in-3-3/
1 flow-control state 出现带来问题
当组件出现flow-control state的时候，rabbitmq会限制客户端publish的速度，降低系统的TPS
2 流量控制组件
connections、channels、queues 都可能出现流量控制情况flow-control state。所以有必要定位是哪个组件出现流量控制了
消息的流程：
Network
↓
Connection process - AMQP parsing, channel multiplexing
↓
Channel process - routing, security, coordination
↓
Queue process - in-memory messages, persistent queue indexing
↓
Message store - message persistence
3 组件出现流量控制的原因
connection flow 一般是 queue到达了瓶颈造成的，即本级的瓶颈可能是下一级消费能力不足造成的（queue的消费能力不足，但看着queue很正常）
queue flow 可能是消息存储持引起的，常见于大量消息需要持久化。即大量的消息发送到持久化的队列中，容易造成队列的flow。
4 Consumer utilisation 消费者利用率
The definition of consumer utilisation is the proportion of time that a queue's consumers could take new messages
消费者利用率，就是消费者能够从队列中获取新的消息的时间比例
消费者利用率值0%-100%，N/A表示没有消费者，如果是100%,则queue不需要等待消费者，queue最大的速度push给消费者，如果是小于100%，表明消费者有时候不能take到消息。网络拥塞和太小的prefetch limit都有可能造成小于100%的利用率
例如：the queue will have to wait until the consumer acks a message before it can send another
queue会等待consumer回复的ack，才回发送下个消息，故一定程度的提高prefech limit的值会提高利用率，可以自己测一个最佳值出来。prefech limit太大，利用率的提升并不明显。上面老外的参考文章中30是比较好的