【Broker簡述】
Broker是RocketMQ的核心，大部分“重量級”的工作都是由Broker完成的，包括：
1.接受Producer發過來的消息；
2.處理Consumer的消費信息請求；
3.消息的持久化存儲；
4.消息的HA機制；
5.服務端的過濾功能。
【消息存儲】
分布式消息隊列因為有高可靠性的要求，所以數據要通過磁盤進行持久化存儲。
RocketMQ的消息是存儲到磁盤上的，這樣既可以保證斷電后恢復，也可以不受內存大小的限制。
[ 磁盤存儲的“快”——順序寫 ]
磁盤存儲，使用得當，磁盤的速度完全可以匹配上網絡的數據傳輸速度，目前的高性能磁盤，順序寫速度可以達到600MB/s，超過了一般網卡的傳輸速度。
[ 磁盤存儲的“慢”——隨機寫 ]
磁盤的隨機寫的速度只有100KB/s，和順序寫的性能差了好幾個數量級。
【消息的存儲結構】
RocketMQ的存儲是由ConsumeQueue和CommitLog配合完成的。
RocketMQ的存儲結構圖
CommitLog以物理文件的方式存放，每台Broker上的CommitLog被本機器所有ConsumeQueue共享。
在CommitLog，一個消息的存儲長度是不固定的，RocketMQ采用了一些機制，盡量向CommitLog中順序寫，但是隨即讀。
[ 存儲機制這樣設計的好處——順序寫，隨機讀 ]
1.CommitLog順序寫，可以大大提高寫入的效率；
2.雖然是隨機讀，但是利用package機制，可以批量地從磁盤讀取，作為cache存到內存中，加速后續的讀取速度。
3.為了保證完全的順序寫，需要ConsumeQueue這個中間結構，因為ConsumeQueue里只存儲偏移量信息，所以尺寸是有限的。在實際情況中，大部分ConsumeQueue能夠被全部讀入內存，所以這個中間結構的操作速度很快，可以認為是內存讀取的速度。
[ 如何保證CommitLog和ConsumeQueue的一致性？ ]
CommitLog里存儲了Consume Queues、Message Queue、Tag等所有信息，即使ConsumeQueue丟失，也可以通過commitLog完全恢復出來。
[ RocketMQ的Broker機器磁盤上的文件存儲結構 ]
【高可用機制】
RocketMQ分布式集群通過Master和Slave機制達到高可用性。
[ 配置中如何區分Master和Slave？ ]
在Broker的配置文件中
Master配置：
brokerId=0 brokerRole=SYNC_MASTER
Slave配置：
brokerId=1 #slave的brokerId>0 brokerRole=SLAVE
Producer只能向Master角色的Broker寫消息。
Consumer可以從Master和Slave角色的Broker讀消息。
[ 如何提高Producer和Consumer的高可用性？ ]
1.Consumer端的高可用
在Consumer配置文件中，不需要設置是從Master還是Slave讀，當Master不可用或者繁忙時，Consumer會被自動切換到從Slave讀。
有了自動切換Consumer的機制，當一個Master角色的Broker出現故障，Consumer依然可以從Slave讀取消息，不影響Consumer程序。
2.Producer端的高可用性
創建Topic的時候，把Topic的多個MessageQueue創建在多個Broker組上（Broker組：相同的Broker名稱，不同的BrokerId組成一個Broker組。），這樣當一個Broker組的Master不可用時，其他組的Master依然可用，Producer依然可以發消息。
[ RocketMQ是否支持把Slave自動轉成Master？ ]
目前不支持，如果機器資源不足，需要把Slave轉成Master，則要手動停止Slave角色的Broker，更改配置文件，用新的配置文件啟動Broker。
【重點：同步刷盤和異步刷盤】
[ 同步刷盤 ]
[ 異步刷盤 ]
[ 同步刷盤或異步刷盤的配置方式 ]
通過Broker配置文件中的flushDiskType參數設置。
flushDiskType=SYNC_FLUSH #同步刷盤
flushDiskType=ASYNC_FLUSH #異步刷盤
【 重點：同步復制和異步復制 】
如果一個Broker組有Master和Slave，消息需要從Master復制到Slave，有同步復制和異步復制兩種方式。
[ 同步、異步復制的優缺點對比 ]
[ 同步異步的配置方式 ]
在Broker的配置文件中的brokerRole參數進行配置：
brokerRole=ASYNC_MASTER #異步復制 brokerRole=SYNC_MASTER #同步復制 brokerRole=SALVE #對於Slave，只有一個參數可選
【小結：推薦的配置方式】
實際業務場景中，要合理設置刷盤方式和主從復制方式。
特別是刷盤方式中的SYNC_FLUSH方式，如果業務頻繁地觸發寫操作，會明顯降低性能。
通常情況下，會把Master和Slave的Broker均配置成ASYNC_FLUSH異步刷盤方式。
主從之間配置成SYNC_MASTER同步復制方式。
即：異步刷盤+同步復制