一、介紹
RocketMQ是阿裡巴巴中間件團隊自研的一款高性能、高吞吐量、低延遲、高可用、高可靠(具備 金融級穩定性)的分布式消息中間件,開源後并于2016年捐贈給Apache社群孵化,目前已經成為了 Apache頂級項目。目前在國内被廣泛的使用,包括網際網路、電商、金融、企業服務等領域,包括:字 節跳動、滴滴、微衆銀行等知名的網際網路公司。
二、使用場景
應用解耦
系統的耦合性越高,容錯性就越低。以電商應用為例,使用者建立訂單後,如果耦合調用庫存系統、 物流系統、支付系統,任何一個子系統出了故障或者因為更新等原因暫時不可用,都會造成下單操作異常,影響使用者使用體驗。
流量削峰
應用系統如果遇到系統請求流量的瞬間猛增,有可能會将系統壓垮。有了消息隊列可以将大量請求 緩存起來,分散到很長一段時間處理,這樣可以大大提高系統的穩定性和使用者體驗。 舉例:業務系統正常時段的QPS如果是1000,流量最高峰是10000,為了應對流量高峰配置高性能 的伺服器顯然不劃算,這時可以使用消息隊列對峰值流量削峰
資料分發
通過消息隊列可以讓資料在多個系統之間進行流通。資料的産生方不需要關心誰來使用資料,隻需 要将資料發送到消息隊列,資料使用方直接在消息隊列中直接擷取資料即可
三、部署架構
RocketMQ的角色介紹
Producer:消息的發送者;舉例:發信者 Consumer:消息接收者;舉例:收信者
Broker:暫存和傳輸消息;舉例:郵局
NameServer:管理Broker;舉例:各個郵局的管理機構
Topic:區分消息的種類;一個發送者可以發送消息給一個或者多個Topic;一個消息的接收者 可以訂閱一個或者多個Topic消息
Message Queue:相當于是Topic的分區;用于并行發送和接收消息
- NameServer是一個幾乎無狀态節點,可叢集部署,節點之間無任何資訊同步。
- Broker部署相對複雜,Broker分為Master與Slave,一個Master可以對應多個Slave,但是一 個Slave隻能對應一個Master,Master與Slave 的對應關系通過指定相同的BrokerName,不 同的BrokerId來定義,BrokerId為0表示Master,非0表示Slave。Master也可以部署多個。 每個Broker與NameServer叢集中的所有節點建立長連接配接,定時注冊Topic資訊到所有 NameServer。 注意:目前RocketMQ版本在部署架構上支援一Master多Slave,但隻有 BrokerId=1的從伺服器才會參與消息的讀負載。
- Producer與NameServer叢集中的其中一個節點(随機選擇)建立長連接配接,定期從 NameServer擷取Topic路由資訊,并向提供Topic 服務的Master建立長連接配接,且定時向 Master發送心跳。Producer完全無狀态,可叢集部署。
- Consumer與NameServer叢集中的其中一個節點(随機選擇)建立長連接配接,定期從 NameServer擷取Topic路由資訊,并向提供Topic服務的Master、Slave建立長連接配接,且定時 向Master、Slave發送心跳。Consumer既可以從Master訂閱消息,也可以從Slave訂閱消 息,消費者在向Master拉取消息時,Master伺服器會根據拉取偏移量與最大偏移量的距離 (判斷是否讀老消息,産生讀I/O),以及從伺服器是否可讀等因素建議下一次是從Master還 是Slave拉取。
執行流程:
1. 啟動NameServer,NameServer起來後監聽端口,等待Broker、Producer、Consumer連上 來,相當于一個路由控制中心。
2. Broker啟動,跟所有的NameServer保持長連接配接,定時發送心跳包。心跳包中包含目前 Broker資訊(IP+端口等)以及存儲所有Topic資訊。注冊成功後,NameServer叢集中就有Topic 跟Broker的映射關系。
3. 收發消息前,先建立Topic,建立Topic時需要指定該Topic要存儲在哪些Broker上,也可以在 發送消息時自動建立Topic。
4. Producer發送消息,啟動時先跟NameServer叢集中的其中一台建立長連接配接,并從 NameServer中擷取目前發送的Topic存在哪些Broker上,輪詢從隊列清單中選擇一個隊列, 然後與隊列所在的Broker建立長連接配接進而向Broker發消息。
5. Consumer跟Producer類似,跟其中一台NameServer建立長連接配接,擷取目前訂閱Topic存在 哪些Broker上,然後直接跟Broker建立連接配接通道,開始消費消息