ActiveMQ的集群與高可用

針對大量的消息吞吐量、對MQ可用性要求非常嚴格的場景、或者非常復雜的消息處理關系情況下，單個MQ實例通常已經無法滿足我們的需要，這時候ActiveMQ的集群和高可用方案就對我們很重要了。

1.client的集群

對消費者來說，使用queue即可做到某種意義上的消費者集群，所有消費者共同處理同一類消息。

非持久訂閱的topic，這種功能沒有實現。但是持久訂閱的topic，可以通過Composite Destination機制轉換成針對具體的持久消費者的專用queue，從而實現多個client共同處理同一類消息。參見：http://blog.csdn.net/kimmking/article/details/9773085?

需要注意的是，如果緩存了consumer（例如spring DMLC+cache consumer）情況下使用了prefetch，多個consumer間可能導致消息順序混亂。見：http://activemq.apache.org/what-is-the-prefetch-limit-for.html

2.client的高可用

在客戶端來說，最簡單的高可用方案就是內置的failover機制。它幫助我們在客戶端實現：

• 在某個broker故障時，自動使用其他備用broker
• 強大的斷線重連機制，哪怕是只有一個broker時，也可以用來在broker down掉重啟后，客戶端重新連接上

斷線重連的配置和參數說明參見：http://activemq.apache.org/failover-transport-reference.html

3.broker的集群

broker端，典型的集群方式就是Network Connector，通過橋接的方式把多個broker，一個個的串起來，整個broker網絡就可以作為一個整體，協同工作。

每個connect上去的broker，都會自動在被連接的broker上創建一個client connecttion，并通過Advisory機制共享自己的消費者列表，從而使得消息可以跨過broker在這個網絡上自由流動。也可以設置duplex為true使得這個連通變為雙向的對等網絡。在BrokerA上配置一個指向BrokerB上的network connector，則連接到BrokerA上的各個ConsumerA1、ConsumerA2、ConsumerA3，都可以消費BrokerB上的QueueB里的消息。默認這三個消費者都被當做一個消費者來看待，即如果BrokerB上有一個ConsumerB1消費。

詳細參見：http://blog.csdn.net/kimmking/article/details/8440150?

其實個人感覺更好的集群方式是增加類似kafka和metaq的partition，然后使用zk作為配置中心來協調各個不同的broker實例、以及不同的partition來協同工作，使得broker的讀寫都可以分散進行。

4.broker的高可用

Broker端的高可用主要是Master-Slave實現的冷備，需要結合客戶端的failover來用。

5.8.0以前的版本，支持三種Master-Slave：

基于共享儲存的Master-Slave：多個broker實例使用一個存儲文件，誰拿到文件鎖就是master，其他處于待啟動狀態，如果master掛掉了，某個搶到文件鎖的slave變成master。由于使用的還是master的存儲文件，所以數據好似一致的。

基于JDBC的Master-Slave：使用同一個數據庫，拿到LOCK表的寫鎖的broker成為master，機制同上。

Pure?Master-Slave：Slave的broker，簡單的從Master復制數據和狀態，問題較多，已被廢棄。

5.9.0版本以后，Pure Master-Slave機制被廢棄，新添加了基于zk的復制LevelDB存儲Master-Slave機制。

此外還有一種可選方式就是，使用某種存儲復制技術，比如Raid、或是DB的replication等等機制來同步存儲，在故障的時候，使用這個復制的存儲恢復broker。

詳細參見：http://activemq.apache.org/masterslave.html?

總結

以上是生活随笔為你收集整理的ActiveMQ的集群与高可用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。