rabbitmq集羣架構(轉載)

rabbitmq集羣四種架構模式：

一、主備模式 （Warren)
二、鏡像模式 （Mirror)
三、遠程模式   (Shovel)
四、多活模式 （Federation) 

 

主備模式：開發中最直接的模式就是主備模式：主要實現RabbitMQ的高可用集羣，通常在併發和數據量不高的狀況下，這種模型很是的好用且簡單，主備模式也稱爲Warren模式。也就是一主一備，對於集羣來講至少有兩臺 雲服務器，那麼這兩臺 服務器一臺在工做，一臺在閒置，注意，這個的主備和咱們以前的主從是不同的，主從的話是一臺做爲主服務器，一臺做爲從服務器，雖然這兩臺是數據同步，主負責讀寫，而從只負責只讀，而主備是一臺工做一臺閒着，若是一臺服務器宕機了，那麼備服務器切換過來，可能的話，這種對於負載均衡的話一臺只忙着幹活，一臺只閒着，這種的生產中用的也不多，這種會形成咱們資源的一個浪費。

 

鏡像模式：集羣模式很是經典的就是Mirror鏡像模式，保證100%數據不丟失，在實際工做中也是用的最多的，並且實現集羣也很是簡單，通常互聯網大廠都會構建這種鏡像集羣模式，原理主要是在主備的基礎上進行了擴展，集羣中全部的節點設備都是同步的，每個隊列，交換機裏面的配置信息和咱們的數據都是同步的，對於這些鏡像在底層同時進行工做，前面的話採用一個負載均衡器，採用nginx或者haproxy也好，進行負載均衡。

 

遠程模式：遠程模式能夠實現雙活的一種模式，簡稱Shovel模式，所謂Shovel就是咱們能夠把消息進行不一樣數據中心的複製工做，咱們能夠跨地域的讓兩個MQ集羣互聯，好比說一個集羣，咱們都會放在一個機房裏面，那麼若是北京的機房出現了一些事故停電，或者天然災害，那麼這個集羣都會宕機了，那麼在咱們對數據要求極高的大型應用咱們須要設置多活或者雙活的模式，也就是要搭建多個數據中心，或者多套集羣，那麼這些集羣能夠一個會放在上海，一個放在北京，還有應放在廣州，三個集羣數據都是同步的，中間有任何一個集羣出現了問題，立刻靈活的切換，那麼這三個集羣都是能夠訪問的話，咱們可能會按照距離，或者訪問速度來進行優先選擇哪組集羣，或者數據中心進行訪問，全部多活模式，在銀行開發的時候通常也叫作容災的機制，至少構建兩套集羣放在不一樣的地域，一個有問題了，立馬進行切換，不至於整個系統宕機，這就是多活模式，在多活模式中MQ也提供了相應的實現方式，早期使用的Shovel模式，這個模式是mq自帶的一種模式，主要就是能夠把消息在不一樣的數據中心進行負載分發，主要就是能夠實現跨地域的讓兩個mq集羣進行互聯。

那麼這個shovel模式須要統一的版本，網絡達到一個什麼樣的水平，配置的話也是有些複雜，這種的話目前已經淘汰了，在真正的數據複製的狀況下，會使用多活模式。

多活模式:這種模式也是實現異地數據複製的主流模式,這種模式是依賴rabbimq的fedrtation插件的模式
自己不是mq自帶的東西，是在mq上進行了擴展，而這種擴展是實現的可靠的AMQP的數據通訊，所以配置起來也比較容易，至關於配置簡單化以後的shovel。

 

原文地址：https://www.yisu.com/zixun/115327.html