您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關RocketMQ集群流程以及核心概念的示例分析的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
一個集群既有Master節點又有Slave節點。
每個 Master 配置一個 Slave,有多對Master-Slave, HA采用同步雙寫方式,主備都寫成功,向應用返回成功。
優點:數據與服務都無單點, Master宕機情況下,消息無延遲,服務可用性與數據可用性都非常高。
缺點:性能比異步復制模式略低,大約低 10%左右,發送單個消息的 RT會略高。目前主宕機后,備機不能自動切換為主機,后續會支持自動切換功能。
要想真正意義的保證消息不丟失,這個同步雙寫是必須的 。
一個topic的queue可以分布到多個Broker上。比如一個topic有4個queue,他可能分配到broker-a上三個queue,broker-b上1個queue,這個queue的分配是由broker端決定的。但是為了驗證猜想我們可以手動從管控臺去創建這個topic,成功的話可以驗證我們的猜想。
首先我有2M2S的一個集群
創建topic
創建topic
查看status,可以發現為我們在每個broker上都創建了4個queue,也就是一共8個queue了。
點擊【TOPIC CONFIG】更改配置
再次查看就會發現已經生效了,驗證了我們的猜想
每個queue的消息都是不一樣的,也就是比如你發N條消息,他可能一部分在broker-a上一部分在broker-b上,不管他在哪,消息都是不一樣的,不要理解成M-S那種復制。他只是負載均衡將queue分配到了不同的broker上。
感謝各位的閱讀!關于“RocketMQ集群流程以及核心概念的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。