参考:
/
/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是比较好的