本文主要是介绍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 + 磁盘一起读取的
在进行消息拉取的时候，先读
这篇关于RocketMQ - 消费者到底是根据什么策略从Master或Slave上拉取消息的？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
