深入浅出 RocketMQ 消息队列 笔记（10）

RocketMQ的消息存储 用一个CommitLog所有分发给该broker的消息，多Topic混合存储 commitLog超过1G，会新起一个commitLog 每条消息存储到commitLog都会在consumeQueue生成一条记录，可以视为一个索引（稠密索引） Kafka的消息存储 Kafka在Topic下也分了多个队列来提高消费的并发度，但在Kafka不叫队列，叫分区partition Kafka的消息存储和RocketMQ略有不同，Kafka的消息存储以Partition为单位进行存储 每个Topic的每个分区都有自己的消息文件、索引文件和时间索引文件，他们的文件名相同，后缀名不同 文件名的命名规则是第一条消息 的offset，文件写满会新起一个文件 索引文件设计的和RocketMQ不同，Kafka是每隔几条消息再创建一条索引，节省了存储空间，能保存更多的索引，这样的索引叫稀疏索引 稀疏索引如何找到对应消息 通过offset找到对应的索引文件，通过二分遍历找到离消息最近的索引，再通过这个索引找到消息文件里此条消息的位置，再遍历消息文件找到目标消息 Kafka时间复杂度：O(log2n)+O(m)，n为索引个数，m为稀疏程度 RocketMQ时间复杂度：O(1) 所以这里就需要权衡利弊了，Kafka是时间换空间，RocketMQ是空间换时间 虽然Kafka是按分区存储消息，但这样可能会引起 Kafka的存储设计对数据复制和迁移很友好，但在海量Topic、Partition场景会有性能问题