一、Broker概述
Broker是 RocketMQ 的核心，大部分‘重量級”工作都是由 Broker完成的。
包括接收 Producer 發過來的消息、處理 Consumer 的消費消息請求、消息的持 久化存儲、消息的 HA 機制以及服務端過濾功能等 。
二、消息的存儲與轉發
分佈式隊列因爲有高可靠性的要求，所以數據要通過磁盤進行持久化存儲 。
磁盤順序寫速度可以達到 600MB/s，但是隨機寫的速度只有大概 lOOKB/s。
RocketMQ 充分利用了這個特性，提高消息存盤和網絡發送的速度 。
三、消息存儲結構
1.RocketMQ消息的存儲形式：ConsumeQueue + CommitLog
-
CommitLog：
消息真正的物理存儲文件，每臺 Broker上的 CommitLog被本機器所有 ConsumeQueue 共享。 -
ConsumeQueue:
消息的邏輯隊列，類似數據庫的索引文件，存儲的是指向物理存儲的地址。每個 Topic下的每個 Message Queue都有一個對應的 ConsumeQueue文件。
在 CommitLog 中，一個消息的存儲長度是不固定的，RocketMQ 採取一些機制，儘量向 CommitLog 中順序寫，但是隨機讀，每次讀取消息隊列先讀取consumer Queue,然後再通過consumerQueue去commitLog中拿到消息主體。
(ConsumeQueue 的內容也會被寫到磁盤裏作持久存儲 )
2.此存儲結構下的優勢
- CommitLog順序寫，大大提高寫入效率
- 雖然是隨機讀，但是利用操作系統的 pagecache 機制，可以批量地從磁盤讀取作爲 cache存到內存中，加速後續的讀取速度。
- 爲了保證完全的順序寫，需要 ConsumeQueue 這個中間結構，在實際情況中，大部分的 ConsumeQueue 能夠被全部讀入內存，所以這個中間結構的操作速度很快，可以認爲是內存讀取的速度 。
四、高可用機制
RocketMQ 分佈式集羣是通過 Master 和 Slave 的配合達到高可用性的
1.消費端的高可用：
Master角色的 Broker支持讀和寫， Slave角色的 Broker僅支持讀
當 Master 不可用或者繁忙的時候， Consumer 會被自動切換到從 Slave 讀 。
當一個 Master 角色的機器出現故障後， Consumer 仍然可以從 Slave 讀，不影響 Consumer 程序 。
2.發送端的高可用：
在創建 Topic 的時候，把 Topic 的多個 Message Queue創建在多個 Broker組上
(相同 Broker名稱，不同 brokerId 的 機器組成 一 個 Broker 組)，
這樣當一個Broker 組的 Master 不可用後，其他組的 Master 仍然可用， Producer 仍然可以發送消息 。
五、同步刷盤和異步刷盤
同步刷盤方式 :
在返回寫成功狀態時，消息已經被寫入磁盤 。 消息寫入內存的 PAGECACHE 後，立刻通知刷盤線程刷盤，然後等待刷盤完成，刷盤線程執行完成後喚醒等待的線程，返回消息寫成功的狀態 。
異步刷盤方式 :
在返回寫成功狀態時 ，消息可能只是被寫入了內存的 PAGECACHE，寫操作的返回快，吞吐量大 ;
當內存裏的消息量積累到一定程度時，統一觸發 寫磁盤動作，快速寫人 。
注意：
刷盤方式通過 Broker 配置文件裏的 flushDiskType 參數進行設置：
SYNC_FLUSH 同步刷盤
ASYNC_FLUSH 異步刷盤
六、同步複製和異步複製
如果一個 Broker組有 Master和 Slave, 消息需要從 Master複製到 Slave上。
同步複製方式：
Master 和 Slave 均寫成功 後才反饋給客戶端寫成功狀態
異步複製方式：
只要 Master 寫成功即可反饋給客戶端寫成功狀態 。
注意：
1.複製方式是通過 Broker 配置文件裏的 brokerRole 參數進行設置：
ASYNC MASTER 異步複製
SYNC MASTER 同步複製
SLAVE 無影響
2.通常情況下，應該把
刷盤方式配置成 ASYNC_FLUSH
主從複製方式配置成 SYNC_MASTER
這樣即使有一臺機器出故障，仍然能保證數據不丟。