除了內置的RabbitMQ集群方案,還可以通過其它一些軟件或者插件來構建RabbitMQ集群.這些方案可以解決一些讓我們頭痛不已的問題,當然它們也不是銀彈,也有使用場景的限制.事實上,對於各種集群方案我們都不能假設太多,每當連入一個節點,我們都要把這個節點當成一個全新的節點來處理,首先要完成各種聲明工作.
下面的方式都沒有實踐過,暫且記錄一筆,留點印象,后面實踐之后豐富.下面的截圖來自"RabbitMQ in Action"
HAProxy
開源項目HAProxy 的定位是:The Reliable, High Performance TCP/HTTP Load Balancer.官網地址 http://haproxy.1wt.eu/我們可以把獨立的RabbitMQ節點隱藏在HAProxy后面,HAProxy完成了下面的職責:
[1] 負載均衡 幫助我們進行節點選擇 HAProxy 實現了一些經典的負載均衡算法 比如:roundrobin leastconn 完整的列表請查看 http://cbonte.github.com/haproxy-dconv/configuration-1.5.html#4-balance
[2] 異常節點檢測
使用HAProxy可以不同策略來構建RabbitMQ集群,最典型的用法是:在一組Rabbit節點前端放置HAProxy做負載均衡,看下面的圖:
使用這種方式構建集群,和我們做WebServer集群一樣,把一批功能相同的Web Server隱藏在HAProxy后面.如果節點宕掉如何處理?這種情況,應用程序並不知道自己實際連接的是哪個節點, cancellation notification消息可以顯示得到連接到的節點已經宕掉.
Warrens 替補隊員
之前提到過使用built-in方式構建集群環境durable queue的問題:隊列只有元數據會在集群的所有節點同步,但是隊列中的數據只會存在於一個節點;這不免讓人失望:數據沒有冗余容易丟數據甚至在durable的情況下,如果所在的節點當掉就要等待節點恢復.
使用HAProxy添加backup節點的方式可以在當前活躍節點宕掉之后盡快啟用備用節點,恢復正常服務.
backup節點在沒有投入使用的時候都處於靜默狀態,並不從活躍節點同步消息.活躍節點在崩潰之前積壓沒有處理的消息只有等待其重啟恢復之后才能啟用.還有一個方法是讓active和backup節點共享存儲文件,這里有兩個問題:1.共享存儲 之前造成active node崩掉的數據可能繼續讓backup崩掉 2.要共享存儲要求節點名完全一致,換句話說兩個節點不可能同時啟動,這就達不到我們的目的了
Shovel:WAN環境使用Cluster
Erlang OTP對網絡延遲敏感,所以RabbitMQ一樣不建議在WAN環境使用集群.在WAN環境可以使用Shovel 實現跨地域數據同步.
最后小圖一張:
