RocketMQ高性能之底层存储设计
【推荐阅读】微服务还能火多久?>>> 说在前面 RocketMQ在底层存储上借鉴了Kafka,但是也有它独到的设计,本文主要关注深刻影响着RocketMQ性能的底层文件存储结构,中间会穿插一点点Kafka的东西以作为对比。 例子 Commit Log,一个文件集合,每个文件1G大小,存储满后存下一个,为了讨论方便可以把它当成一个文件,所有消息内容全部持久化到这个文件中;Consume Queue:一个Topic可以有多个,每一个文件代表一个逻辑队列,这里存放消息在Commit Log的偏移值以及大小和Tag属性。 为了简述方便,来个例子 假如集群有一个Broker,Topic为binlog的队列(Consume Queue)数量为4,如下图所示,按顺序发送这5条内容各不相同消息。 发送消息 先简单关注下Commit Log和Consume Queue。 RMQ文件全貌 RMQ的消息整体是有序的,所以这5条消息按顺序将内容持久化在Commit Log中。Consume Queue则用于将消息均衡地排列在不同的逻辑队列,集群模式下多个消费者就可以并行消费Consume Queue的消息。 Page Cache 了解了每个文件都在什么位置存放什么内容,那接下来就正式开始讨论这种存储方案为什么在性能带来的提升。 通常文件读写比较慢,如果对文件进行顺序读写,速度几乎是接近于内存的随机读写