rabbitmq單機多例項叢集與負載均衡

engourdi發表於2014-02-17
MQ負載

1.rabbitmq叢集

單機多例項的叢集測試

10.5.16.222上

$ RABBITMQ_NODE_PORT=5672 RABBITMQ_NODENAME=rabbit1 rabbitmq-server -detached

$ RABBITMQ_NODE_PORT=5673 RABBITMQ_NODENAME=hare1 rabbitmq-server -detached

$ rabbitmqctl -n hare stop_app

$ rabbitmqctl -n hare join_cluster rabbit@`beta`

$ rabbitmqctl -n hare start_app

 

停掉

root@beta:~# rabbitmqctl -n hare1 stop

Stopping and halting node hare1@beta ...

...done.

root@beta:~# rabbitmqctl -n rabbit1 cluster_status

Cluster status of node rabbit1@beta ...

[{nodes,[{disc,[hare1@beta,rabbit1@beta]}]},

 {running_nodes,[rabbit1@beta]},

 {partitions,[]}]

...done.

重新啟動hare1

root@beta:~# rabbitmqctl -n hare1 cluster_status

Cluster status of node hare1@beta ...

[{nodes,[{disc,[hare1@beta,rabbit1@beta]}]},

 {running_nodes,[rabbit1@beta,hare1@beta]},

 {partitions,[]}]

...done.

 

 

         單機簡單叢集搭建完畢，使用訊息傳送與接收測試，增加節點客戶端訊息接收器需重啟，刪除節點不需重新配置，使用映象佇列可防止訊息單節點丟失，但效能會打折扣。

         減少客戶端配置可以使用dns伺服器來代替ip+埠，也可以使用下一節調研的負載均衡器。


2.負載均衡（可選）

於是在另外一臺128上搭建tcp負載均衡器

 

10.5.16.128

apt安裝haproxy

配置 /etc/haproxy/haproxy.cfg：

listen rabbitmq 0.0.0.0:56720

mode tcp

balance roundrobin

option tcpka

server rabbit1 10.5.16.222:5672 check inter 5000 rise 2fall 5

server hare1 10.5.16.222:5673 check inter 5000 rise 2fall 5

 

客戶端配置到haproxy所在伺服器的地址與監聽埠

       stats uri /haproxy-stats

        stats realm Haproxy\ statistics

        stats auth franklin:111111

狀態監聽http://XXX/haproxy-stats

 

3.映象佇列

spring 映象佇列配置

<rabbit:template id="amqpTemplate" connection-factory="connectionFactory" reply-queue-arguments="haArgs" />

    <rabbit:queue auto-delete="true" durable="false"id="mailQueue"

        name="#{config.project.mailQueueName}" queue-arguments="haArgs"></rabbit:queue>

    <rabbit:queue-arguments id="haArgs">

        <entry key="x-ha-policy" value="all" />

    </rabbit:queue-arguments>



 4.額外參考說明

    不做映象佇列的話，節點down掉則必須等他回覆，不然訊息就丟失了。master節點退出叢集會選一個slave作為master,那麼要是不幸選中了一個剛剛加入叢集的節點怎麼辦?不就丟訊息了麼?放心RabbitMQ會維護節點的狀態是否已經同步,使用rabbitmqctl的synchronised_slave_pids引數,就可以檢視狀態. 對於publish，客戶端任意連線叢集的一個節點，轉發給建立queue的節點儲存訊息的所有資訊；

    對於consumer，客戶端任意連線叢集中的一個節點，如果資料不在該節點中，則從儲存該訊息data的節點拉取。可見當儲存有queue內容的節點失效後，只要等待該節點恢復後，queue中存在的訊息才可以獲取消費的到。顯然增加叢集的節點，可以提高整個叢集的吞吐量，但是在高可用方面要稍微差一些

   mirror queue是為rabbitMQ高可用的一種方案，相對於普通的叢集方案來講，queue中的訊息每個節點都會存在一份copy,這個在單個節點失效的情況下，整個叢集仍舊可以提供服務。但是由於資料需要在多個節點複製，在增加可用性的同時，系統的吞吐量會有所下降。

在實現機制上，mirror queue內部實現了一套選舉演算法，有一個master和多個slave,queue中的訊息以master為主，對於publish，可以選擇任意一個節點進行連線，rabbitmq內部若該節點不是master，則轉發給master，master向其他slave節點傳送該訊息，後進行訊息本地化處理，並組播複製訊息到其他節點儲存，對於consumer，可以選擇任意一個節點進行連線，消費的請求會轉發給master,為保證訊息的可靠性，consumer需要進行ack確認，master收到ack後，才會刪除訊息，ack訊息會同步(預設非同步)到其他各個節點，進行slave節點刪除訊息。若master節點失效，則mirror queue會自動選舉出一個節點（slave中訊息佇列最長者）作為master，作為訊息消費的基準參考;在這種情況下可能存在ack訊息未同步到所有節點的情況(預設非同步)，若slave節點失效，mirror queue叢集中其他節點的狀態無需改變。

 

相關文章