主備模式

主備與主從

• 主備和主從的概念是有區別的，主備是主節點可以提供讀寫的，從節點是不提供任何讀寫的，只是一個備用的服務。
• 主要的目的就是在主節點產生故障或者宕機的時候它能夠實現一個自動切換，由原來的主節點切換到我們的備用節點，由備用節點繼續提供讀寫服務，這時候備用節點就是充當主節點的角色了。而原來的節點恢復后又會加入到集群中，變成了備用節點。
• 主從是主服節點可以提供讀寫，但從節點是只讀的。主從更多的是實現讀寫分離和數據備份的效果。

主備模式

• 主備模式，也稱之為Warren模式，即主節點如果掛了，切換到從節點繼續提供服務，和activemq利用zookeeper做主/備是一樣的效果。
• 主備未必是兩個節點，可以一主多備。
• 主備模式：實現RabbitMQ的高可用集群，一般在并發和數據量不高的情況下，這種模型非常的好用且簡單。

主備集群架構

如圖為主備模式的簡單架構模型，主要是利用HaProxy去做的主備切換，當主節點掛掉時，HaProxy會自動進行切換，把備份節點升級為主節點

HaProxy配置

HAProxy 是一款提供高可用性、負載均衡以及基于TCP(第四層)和HTTP(第七層)應用的代理軟件， 簡單了解一下它的相關配置

#監聽集群
listen rabbitmq_cluster
bind 0.0.0.0:5672
#配置TCP模式
mode tcp
#簡單的輪詢
balance roundrobin
#主節點
server rxy76 192.168.143.76:5672 check inter 5000 rise 2 fall 3
#備用節點，rxy77代表主機名，backup代表備份節點
server rxy77 192.168.143.77:5672 backup check inter 5000 rise 2 fall 3 
備注: rabbitmq集群節點配置 
# inter每隔五秒對mq集群做健康檢查，2次正確證明服務器可用，3次失敗證明服務器不可用，并且配置主備機制

遠程模式(Shovel)

• 遠程模式：遠距離通信和復制，可以實現雙活的一種模式，簡稱Shovel模式。
• 所謂Shovel就是我們可以把消息進行不同數據中心的復制工作，我們可以跨地域的讓倆個mq集群互聯。

架構模型

Shovel架構模型：綠色部分就代表了兩個不同地域的MQ節點，假設用戶在A地方下一個訂單，然后訂單投遞到了MQ，第一個地方的MQ節點為了避免壓力過大、負載過高可以設置一個閾值，如果負載過高將訂單信息轉到另一個地方的MQ，分攤服務壓力。同時也可以進行兩個或多個中心的數據同步。

好處：在使用了shovel插件后，模型變成了近端同步確認，遠端異步確認的方式，大大提高了訂單確認速度，并且還能保證可靠性

怎么去做的？

Shovel集群的拓撲圖如下所示 ，一個訂單進來之后，里面有兩個隊列，如果正常隊列壓力過大，會將訂單路由到backup隊列，這個隊列和另一個地域的MQ(某個交換機)產生了Shovel聯系，就會把數據復制到遠端MQ中心，在遠端會有相應的隊列進行消費

遠程模式的使用

• Shovel集群的配置，首先啟動rabbitmq插件，命令如下：
  rabbitmq-plugins enable amqp_client
rabbitmq-plugins enable rabbitmq_shovel
• 創建rabbitmq.config文件：touch /etc/rabbitmq/rabbitmq.config
• 在config文件中添加相關的配置
• 最后我們需要源服務器和目的地服務器都使用相同的配置文件(rabbitmq.config)

事實上這個配置會相對復雜一些，實現雙活已經有更好的方式，所以遠程模式了解即可。

鏡像模式

• 鏡像模式：集群模式非常經典的就是Mirror鏡像模式，保證100%數據不丟失，在實際工作中也是用的最多的。
• 并且實現集群非常的簡單，一般互聯網大廠都會構建這種鏡像集群模式。
• Mirror鏡像隊列，目的是為了保證rabbitmq數據的高可靠性解決方案，主要就是實現數據的同步，一般來講是2-3個節點實現數據同步(對于100%數據可靠性解決方案一般是3節點)

集群架構

黃色的就是應用服務器，里面包含了RabbitMQ節點，節點里面有個Mirror queue，這三個鏡像隊列數據是要同步的。
外部發送一條消息，落到一臺服務器上，這臺服務器將數據進行同步，同步到另外兩個節點上。
利用HA-proxy做負載均衡，然后KeepAlived做多個HA-proxy的高可用切換

多活模式(Federation)

• 多活模式：這種模式也是實現異地數據復制的主流模式，因為Shovel模式配置比較復雜，所以一般來說實現異地集群都是使用這種雙活或者多活模型來實現的。
• 這種模型需要依賴rabbitmq的federation插件，可以實現持續的可靠的AMQP數據通信，多活模式在實際配置與應用上非常的簡單。
• 提供了更可靠的完備的數據保障，即使一個集群掛掉，也還有另外一個集群。
• RabbitMQ部署架構采用雙中心模式(多中心) , 那么在兩套(或多套)數據中心中各部署一套RabbitMQ集群，各中心的RabbitMQ服務除了需要為業務提供正常的消息服務外，中心之間還需要實現部分隊列消息共享。

多活集群架構

上層就是應用層，然后經過LBS負載均衡，兩套RabbitMQ集群，可能是兩套鏡像隊列，兩套集群通過federation插件進行數據的復制和流轉。
當然federation插件不是建立在集群上的，而是建立到單個節點上，比如左邊node3可以和右邊任意一臺建立這種多活機制，然后，自己這邊的集群如果是采用鏡像隊列那么也會去進行同步，所以這種性能也是非常好的。

Federation插件說明

• Federation插件是一個不需要構建Cluster，而在Brokers之間傳輸消息的高性能插件，Federation 插件可以在Brokers或者Cluster之間傳輸消息，連接的雙方可以使用不同的users和virtual hosts，雙方也可以使用版本不同的RabbitMQ和Erlang
• Federation 插件使用AMQP協議通訊，可以接受不連續的傳輸
• Federation Exchanges，可以看成Downstream從Upstream主動拉取消息，但并不是拉取所有消息，必須是在Downstream上已經明確定義Bindings關系的Exchange，也就是有實際的物理Queue來接收消息，才會從Upstream拉取消息到Downstream。使用AMQP協議實施代理間通信，Downstream會將綁定關系組合在一起，綁定/解除綁定命令將發送到Upstream交換機。因此，FederationExchange只接收具有訂閱的消息。

流轉過程

• 如圖所示上游服務和下游服務，建立一個Link連接，可以認為就是federation，X代表Exchange
• 上游過來的數據，可以通過Exchange，直接轉到下游，下游Exchange去接收數據，然后路由到具體的隊列進行消費。
• 上游過來的數據不是說所有的數據都會流轉到下游的，而是說建立連接關系，下游需要有具體的隊列進行存儲。
• 上游也可以自己去監聽，同一個數據可以發到兩個集群中，都可以用隊列去接收存儲然后消費。