由於對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
然后就是以此類推