RocketMQ - 消费者到底是根据什么策略从Master或Slave上拉取消息的？

消费消息，可以从Master Broker拉取，也可以从Slave Broker拉取，那到底什么时候从Master Broker拉取，什么时候从Slave Broker拉取？

之前有提到刚开始消费者都是从Master Broker机器上去拉取消息的，然后如果Master Broker机器觉得自己负载比较高，就会告诉消费者机器，下次可以从Slave Broker机器去拉取。

1. ConsumeQueue文件也是基于os cache的

ConsumeQueue会被大量的消费者发送的请求给高并发的读取，所以ConsumeQueue文件的读操作是非常频繁的，而且同时会极大的影响到消费者进行消息拉取的性能和消费吞吐量。

所以实际上broker对ConsumeQueue文件同样也是基于os cache来进行优化的。

也就是说，对于Broker机器得到磁盘上的大量的ConsumeQueue文件，在写入的时候也是优先进入os cache中的。

而且之前也了解到ConsumeQueue文件主要是存放消息的offset，所以每个文件很小，30万条消息的offset就只有5.72MB而已，所以实际上ConsumeQueue文件他们是不占用多少磁盘空间的，他们整体数据量很小，几乎可以完全被os 缓存在内存cache中。

所以实际上在消费者机器拉取消息的时候，第一步大量的频繁读取ConsumeQueue文件，几乎可以说就是跟读内存里的数据的性能是一样的，通过这个就可以保证数据消费的高性能以及高吞吐。

2. CommitLog是基于os cache + 磁盘一起读取的

在进行消息拉取的时候，先读