主備模式

主備與主從

• 主備和主從的概念是有區(qū)別的，主備是主節(jié)點(diǎn)可以提供讀寫的，從節(jié)點(diǎn)是不提供任何讀寫的，只是一個(gè)備用的服務(wù)。
• 主要的目的就是在主節(jié)點(diǎn)產(chǎn)生故障或者宕機(jī)的時(shí)候它能夠?qū)崿F(xiàn)一個(gè)自動切換，由原來的主節(jié)點(diǎn)切換到我們的備用節(jié)點(diǎn)，由備用節(jié)點(diǎn)繼續(xù)提供讀寫服務(wù)，這時(shí)候備用節(jié)點(diǎn)就是充當(dāng)主節(jié)點(diǎn)的角色了。而原來的節(jié)點(diǎn)恢復(fù)后又會加入到集群中，變成了備用節(jié)點(diǎn)。
• 主從是主服節(jié)點(diǎn)可以提供讀寫，但從節(jié)點(diǎn)是只讀的。主從更多的是實(shí)現(xiàn)讀寫分離和數(shù)據(jù)備份的效果。

主備模式

• 主備模式，也稱之為Warren模式，即主節(jié)點(diǎn)如果掛了，切換到從節(jié)點(diǎn)繼續(xù)提供服務(wù)，和activemq利用zookeeper做主/備是一樣的效果。
• 主備未必是兩個(gè)節(jié)點(diǎn)，可以一主多備。
• 主備模式：實(shí)現(xiàn)RabbitMQ的高可用集群，一般在并發(fā)和數(shù)據(jù)量不高的情況下，這種模型非常的好用且簡單。

主備集群架構(gòu)

如圖為主備模式的簡單架構(gòu)模型，主要是利用HaProxy去做的主備切換，當(dāng)主節(jié)點(diǎn)掛掉時(shí)，HaProxy會自動進(jìn)行切換，把備份節(jié)點(diǎn)升級為主節(jié)點(diǎn)

HaProxy配置

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

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

遠(yuǎn)程模式(Shovel)

• 遠(yuǎn)程模式：遠(yuǎn)距離通信和復(fù)制，可以實(shí)現(xiàn)雙活的一種模式，簡稱Shovel模式。
• 所謂Shovel就是我們可以把消息進(jìn)行不同數(shù)據(jù)中心的復(fù)制工作，我們可以跨地域的讓倆個(gè)mq集群互聯(lián)。

架構(gòu)模型

Shovel架構(gòu)模型：綠色部分就代表了兩個(gè)不同地域的MQ節(jié)點(diǎn)，假設(shè)用戶在A地方下一個(gè)訂單，然后訂單投遞到了MQ，第一個(gè)地方的MQ節(jié)點(diǎn)為了避免壓力過大、負(fù)載過高可以設(shè)置一個(gè)閾值，如果負(fù)載過高將訂單信息轉(zhuǎn)到另一個(gè)地方的MQ，分?jǐn)偡?wù)壓力。同時(shí)也可以進(jìn)行兩個(gè)或多個(gè)中心的數(shù)據(jù)同步。

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

怎么去做的？

Shovel集群的拓?fù)鋱D如下所示 ，一個(gè)訂單進(jìn)來之后，里面有兩個(gè)隊(duì)列，如果正常隊(duì)列壓力過大，會將訂單路由到backup隊(duì)列，這個(gè)隊(duì)列和另一個(gè)地域的MQ(某個(gè)交換機(jī))產(chǎn)生了Shovel聯(lián)系，就會把數(shù)據(jù)復(fù)制到遠(yuǎn)端MQ中心，在遠(yuǎn)端會有相應(yīng)的隊(duì)列進(jìn)行消費(fèi)

遠(yuǎn)程模式的使用

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

事實(shí)上這個(gè)配置會相對復(fù)雜一些，實(shí)現(xiàn)雙活已經(jīng)有更好的方式，所以遠(yuǎn)程模式了解即可。

鏡像模式

• 鏡像模式：集群模式非常經(jīng)典的就是Mirror鏡像模式，保證100%數(shù)據(jù)不丟失，在實(shí)際工作中也是用的最多的。
• 并且實(shí)現(xiàn)集群非常的簡單，一般互聯(lián)網(wǎng)大廠都會構(gòu)建這種鏡像集群模式。
• Mirror鏡像隊(duì)列，目的是為了保證rabbitmq數(shù)據(jù)的高可靠性解決方案，主要就是實(shí)現(xiàn)數(shù)據(jù)的同步，一般來講是2-3個(gè)節(jié)點(diǎn)實(shí)現(xiàn)數(shù)據(jù)同步(對于100%數(shù)據(jù)可靠性解決方案一般是3節(jié)點(diǎn))

集群架構(gòu)

黃色的就是應(yīng)用服務(wù)器，里面包含了RabbitMQ節(jié)點(diǎn)，節(jié)點(diǎn)里面有個(gè)Mirror queue，這三個(gè)鏡像隊(duì)列數(shù)據(jù)是要同步的。
外部發(fā)送一條消息，落到一臺服務(wù)器上，這臺服務(wù)器將數(shù)據(jù)進(jìn)行同步，同步到另外兩個(gè)節(jié)點(diǎn)上。
利用HA-proxy做負(fù)載均衡，然后KeepAlived做多個(gè)HA-proxy的高可用切換

多活模式(Federation)

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

多活集群架構(gòu)

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

Federation插件說明

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

流轉(zhuǎn)過程

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