功能介紹
Broker充當者消息中轉的角色，負責存儲消息，轉發消息，Broker在RocketMQ系統中負責接收并存儲從生產發送過來的消息，同時為消費者的拉取請求做準備。Broker同時也存儲者消息的元數據，報貨消費者組合消費進度偏移offset,主題，隊列等。
為了增強Broker性能與吞吐量，Broker一般都是以集群的形式出現的，各集群節點中的可能存放著相同topic的不同的queue，不過這里有個問題，如果某個Broker節點宕機，如何保證數據不丟失？解決方案就是將每個Broker集群節點橫向擴展，將每個Broker節點再建一個HA集群，解決單點問題
Broker節點集群是一個主從集群，及集群中的具有Master與Slave兩種角色，Master負責處理讀寫操作請求，而Slave僅僅負責處理讀操作請求，一個Master可以包含多個Slave，但是一個Slave只能隸屬一個Master。Master和Slave的對應關系是通過指定相同的BrokerName，不同的BrokerId來確定，BrokerId 為0 表示Master 非 0 表示Slave,每個Broker和NameServer集群中的所有節點建立長連接，定時注冊Topic信息到所有的NameServer。
工作流程
- 啟動NameServer ，NameServer啟動后開始監聽端口，等待Broker，Producer，Consumer鏈接
- 啟動Broker，Broker會與所有的NameServer建立并保持長連接，然后每個30s向NameServer定時發送心跳包
- 發送消息前，可以先創建Topic，創建Topic時需要指定該主題存儲在那些Broker上，當然，在創建主題的時候也會將主題與Broker關系寫入到NameServer中，不過這步是可選的，也可以在發送消息的時候自動創建主題。
- Producer發送消息，啟動時先跟NameServer集群中的其中一臺建立長連接，并從NameServer中獲取路由信息，即當前發送的Topic的Queue與Broker的地址（ip+port）的映射關系，然后根據算法策略從隊列中選擇一個Queue，與隊列所在的Broker建立長連接從而向Broker發送消息。當然，在獲取到路由信息后，Producer會將路由信息緩存到本地，再每隔30s從NameServer更新一次路由信息。
- Consumer和Producer類似，跟其中的一臺NameServer建立長連接，獲取其訂閱主題的路由信息，然后根據算法策略從路由信息中獲取其所要消費的Queue，然后直接跟Broker建立長連接，開始消費其中的消息。Consumer 在獲取到路由信息后，同樣也會每30s從NameServer更新一次路由信息，不過不同于Producer的是，Consumer還會向Broker發送心跳，以確保Broker的存活狀態。
數據復制與刷盤策略
數據復制策略指的是Broker的master和slave之間的數據同步方式。分為同步復制和異步復制。
- 同步復制：消息寫入master后，master會等待slave同步數據成功后才向producer返回成功的ack。
- 異步復制：消息寫入master后，master立即向producer返回成功的adk,無需等待slave同步數據成功。
數據刷盤策略指的是Broker中消息落盤方式，及消息發送到broker內存后消息持久化到磁盤的方式。分為同步刷盤與異步刷盤
- 同步刷盤：當消息持久化到broker的磁盤后才算是消息寫入成功
- 異步刷盤：當消息寫入到broker的內存后即表示消息寫入成功，無需等待消息持久化到磁盤。
Broker集群模式
單Master
只有一個broker（其本質上就不能稱為集群）。這種方式只能在測試時候使用，生產環境下不能使用，因為存在單點問題
多Master
broker集群僅由多個master構成，不存在Slave。同一個topic的各個queue會平均分配在各個master節點上。
- 優點：配置簡單，單個master宕機或者重啟維護對應用無影響，在磁盤配置為RAID10時，即使機器宕機不可恢復情況下，由于RAID10磁盤非常可靠，消息也不會丟（異步刷盤丟失邵少量消息，同步刷盤一條不丟）性能最高；
- 缺點： 單臺機器宕機期間，這臺機器上未被消費的消息在機器恢復之前不可訂閱（不可消費，但是可以繼續生產），消息的實時性受到影響。
多Master多Slave模式-異步復制
broker集群由多個master構成，每個master又可配置多個slave（在配置了RAID磁盤陣列的情況下，一個master一般配置一個slave即可）。master與slave的關系是主備關系，即master負責消息的讀寫請求，而slave僅負責消息的備份與master宕機后的角色切換。
異步復制即前面說的復制策略中的異步復制策略，即消息寫入master成功后，master立即向producer返回成功的ack,無需等待slave同步數據成功。該模式最大的特點之一是，當master宕機后，slave能夠自動切換為master，不過由于slave從master的同步具有短暫的延遲，所以當master宕機后，這種異步復制的方式可能會存在少量消息丟失的問題。
多Master多Slave模式-同步雙寫
該模式是多master多slave模式的同步復制實現，所謂的同步雙寫，指的就是消息寫入master成功后，master會等待slave同步數據成功后才向producer返回成功的ack,即master與slave都要寫入成功后才返回陳宮的ack,也即雙寫。
該模式的與異步復制模式相比，優點是消息的安全性更高，不存在消息丟失的情況，但單個消息的rt略高，從而導致性能要略低，該模式存在一個大的問題，對目前的版本，master宕機后，slave不能自動切換到master
最佳實踐
一般會為master配置RAID10磁盤陣列，然后再為其配置一個slave，即利用RAID10磁盤陣列的高效，安全性，有解決了可能會影響訂閱的問題。
RAID磁盤陣列的效率要高于master-slave集群，因為RAID是硬件支持的，也正因為如此，所以RAID陣列的搭建成本較高
多master+RAID陣列與多master多slave集群的區別是什么？
- 多master+RAID陣列，其僅僅可以保證數據不丟失，即不影響消息的寫入，但是可能影響到消息的訂閱消費，但其執行效率遠遠高于多master多slave集群
- 多master多slave集群，其不僅可以保證數據不丟失，也不會因影響數消息寫入，其運行效率遠遠低于多master+RAID陣列
消息的生產過程
producer可以將消息寫入到某Broker中的某個queue中，其經歷如下過程：
- Producer發送消息之前，會先向NameServer發送獲取消息topic的路由信息的請求
- NameServer返回該Topic的路由表及Broker列表
擴展:這里的路由表實際是一個map，key為topic名稱，value是一個QueueData實例列表。QueueData并不是一個queue對應一個QueueData，而是一個broker中該topic的所有Queue對應一個QueueData。也就是說只要涉及到該topic的Broker，一個Broker對應一個QueueData,QueueData中包含brokername
broker列表：也是一個map，key為brokerName,value為brokerData,brokerData為一套名稱為brokerName的主從小集群 - producer根據代碼中指定的queue選擇策略，從queue列表中選出一個隊列，用于后續存儲消息。
- producer對消息做一些特殊處理，例如消息本身超過4m,則會對其進行壓縮
- producer向選出的queue所在的broker發出rpc請求，將消息發送到選出的queue。
queue選擇算法
對于無序消息，其queue選擇算法，也稱為消息投遞算法，常見的有兩種
- 輪詢算法：默認的選擇算法，該算法保證了每個queue中可以均勻的獲取到消息
- 最小投遞延遲算法：該算法會統計每次投遞消息的時間延遲，然后根據統計出的結果將消息投遞到時間延遲最小的queue，如果延遲效果相同，則采用輪詢算法投遞。
有序消息可以指定具體的queue。
