這是一個比較宏觀的部署架構圖，rocketmq天然支持高可用，它可以支持多主多從的部署架構，這也是和kafka最大的區別之一

原因是RocketMQ中并沒有master選舉功能，所以通過配置多個master節點來保證rocketMQ的高可用。和所有的集群角色定位一樣，master節點負責接受事務請求、slave節點只負責接收讀請求，并且接收master同步過來的數據和slave保持一直。當master掛了以后，如果當前rocketmq是一主多從，?就意味著無法接受發送端的消息，但是消費者仍然能夠繼續消費。

所以配置多個主節點后，可以保證當其中一個master節點掛了，另外一個master節點仍然能夠對外提供消息發送服務。

當存在多個主節點時，一條消息只會發送到其中一個主節點，rocketmq對于多個master節點的消息發送，會做負載均衡，使得消息可以平衡的發送到多個master節點上。

一個消費者可以同時消費多個master節點上的消息，在下面這個架構圖中，兩個master節點恰好可以平均分發到兩個消費者上，如果此時只有一個消費者，那么這個消費者會消費兩個master節點的數據。

由于每個master可以配置多個slave，所以如果其中一個master掛了，消息仍然可以被消費者從slave節點消費到。可以完美的實現rocketmq消息的高可用

接下來，站在topic的角度來看看消息是如何分發和處理的，假設有兩個master節點的集群，創建了一個TestTopic，并且對這個topic創建了兩個隊列，也就是分區。

消費者定義了兩個分組，分組的概念也是和kafka一樣，通過分組可以實現消息的廣播。?

集群支持?

RocketMQ天生對集群的支持非常友好

1）單Master?

優點：除了配置簡單沒什么優點

缺點：不可靠，該機器重啟或宕機，將導致整個服務不可用

2）多Master?

優點：配置簡單，性能最高

缺點：可能會有少量消息丟失（配置相關），單臺機器重啟或宕機期間，該機器下未被消費的消息在機器恢復前不可訂閱，影響消息實時性

3）多Master多Slave，每個Master配一個Slave，有多對Master-Slave，集群采用異步復制方式，主備有短暫消息延遲，毫秒級

優點：性能同多Master幾乎一樣，實時性高，主備間切換對應用透明，不需人工干預

缺點：Master宕機或磁盤損壞時會有少量消息丟失

4）多Master多Slave，每個Master配一個Slave，有多對Master-Slave，集群采用同步雙寫方式，主備都寫成功，向應用返回成功

優點：服務可用性與數據可用性非常高

缺點：性能比異步集群略低，當前版本主宕備不能自動切換為主

需要注意的是，在RocketMQ里面，1臺機器只能要么是Master，要么是Slave。這個在初始的機器配置里面，就定死了。不會像kafka那樣存在master動態選舉的功能。其中Master的broker id = 0，Slave?的broker id > 0。

有點類似于mysql的主從概念，master掛了以后，slave仍然可以提供讀服務，但是由于有多主的存在，當一個master掛了以后，可以寫到其他的master上。

?

總結

以上是生活随笔為你收集整理的RocketMQ消息发送及消费的基本原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。