topic對應多個partition

同一個伺服器（broke）會有多個

不同topic-partition對，patition為單主多從結構

主掛了會重新選主

訊息直接儲存在partition中，

對單topic為順序寫

缺點：如果伺服器承載的topic過多，相應的patition也會變多，因此會造成隨機寫，導致io效率降低

優點：直接從partition順序讀取資料，效率高

topic對應多個consumequeue，

同一個伺服器會有不現的

topic-consumerqueue對，consumerqueue為多主多從結構

主由配置指定，主掛了其它主提供服務。

同一個伺服器的所有訊息

都統一寫到commitlog中

consumequeue只儲存在

CommiLog中的起始offset，log大小和MessageTag的

hashCode，資料量較少

優點：因為consumequeue資料量小，絕大部分的訪問還是Page Cache的訪問，而不是磁碟訪問。正式部署也可以將CommitLog和consumerQueue放在不同的物理SSD，避免多類檔案進行IO競爭。

Commit Log中儲存了所有的元資訊，包含訊息體，類似於Mysql、Oracle的redolog，所以只要有Commit Log在，Consume Queue即使資料丟失，仍然可以恢復出來

缺點：讀取訊息時，由於不同的topic訊息都寫在同一個檔案，導致讀取順序不連續，造成隨機讀，降低了讀IO，為了優化這個問題rocketmq會預讀取更多的資料到pagecache所以消耗系統記憶體比較大