由于对RocketMq的MessageQueue一直不理解，其实就是可以理解成consumeQueue
有原文为证
CommitLog：是消息主体以及元数据的存储主体，对CommitLog建立一个ConsumeQueue，
每个ConsumeQueue对应一个（概念模型中的）MessageQueue，所以只要有Commit Log在，Consume Queue即使数据丢失，仍然可以恢复出来。
于是我做了个实验
分别读取了四个consumequeue的文件，默认是四个读取队列，所以在consumeQueue目录下有四个文件夹，分别是0，1，2，3
这四个文件夹下都一个文件，文件名就叫 00000000000000000000。我就往topic里写了10条数据
说下三个字段的含义 序号: taghash size offset
0号 [ERROR]1: 2598919 201 603 2: 2598919 201 603 [ERROR]3: 2598919 201 1407 4: 2598919 201 1407 1号 [ERROR]1: 2598919 201 0 2: 2598919 201 0 [ERROR]3: 2598919 201 804 4: 2598919 201 804 [ERROR]5: 2598919 201 1608 6: 2598919 201 1608 2号 [ERROR]1: 2598919 201 201 2: 2598919 201 201 [ERROR]3: 2598919 201 1005 4: 2598919 201 1005 [ERROR]5: 2598919 201 1809 6: 2598919 201 1809 3号 [ERROR]1: 2598919 201 402 2: 2598919 201 402 [ERROR]3: 2598919 201 1206 4: 2598919 201 1206
从这里能看得出来，每一条消息都是201字节大小。可以看得出来第一条消息写在了1号文件，也就是queueId = 1。
2598919 201 0
然后第二个消息在2号文件
2598919 201 201
然后第三条消息在3号文件
2598919 201 402
然后就是以此类推