ActiveMQ集羣

ActiveMQ集羣

1.1 何爲集羣?

集羣就是將相同的程序、功能，部署在兩臺或多臺服務器上，這些服務器對外提供的功能是徹底同樣的。經過不斷橫向擴展增長服務器的方式，以提升服務的能力 。

1.1.1 不集羣模式

1.1.2 集羣模式

1.2 集羣的優點:

 一、集羣能夠解決單點故障問題；

  二、集羣能夠提升系統服務能力；

1.3 ActiveMQ集羣方式


          1.shared filesystem Master-Slave方式主從集羣

• 經過共享存儲目錄（kahaDB）來實現master和slave的主從信息備份；
• 全部ActiveMQ的broker都在不斷地獲取共享目錄的控制權，哪一個broker搶到了控制權，它就成爲master，它將鎖定該目           錄，其餘broker就只能成爲slave；
• 當master主出現故障後，剩下的slave從將再進行爭奪共享目錄的控制權，誰搶到共享目錄的控制權，誰就成爲主；
• 因爲他們是基於共享目錄，因此當主出現故障後，其上沒有被消費的消息在接下來產生的新的master主中能夠繼續進行            消費；
•                                      
  

       2.shared database Master-Slave方式主從集羣
         該方式與shared filesystem方式相似，只是共享的存儲介質由文件系統改爲了數據庫。
                                 

    

   3.Replicated LevelDB Store方式集羣

• 基於可複製的LevelDB存儲方式的集羣
• 這種集羣方式是ActiveMQ5.9之後才新增的特性，它使用ZooKeeper從一組broker中協調選擇一個broker做爲master，其           他broker轉入slave模式；
• 全部slave從節點經過複製master主節點的消息來實現信息同步，當主出現故障後，沒有被消費的消息在從服務器上也同           步了一份，因此不會有信息的丟失；
• LevelDB 是 Google開發的一套用於持久化數據的高性能類庫，ActiveMQ利用該類庫進行數據的存儲；
• 只有master 接受客戶端鏈接，slave不接受客戶端鏈接；
• Master的全部存儲操做都將被複制到slaves；
• 在這個模式中，須要有半數以上的broker是正常的，集羣纔是可用的，超過半數broker故障，zookeeper的選舉算法將不            能選擇master，從而致使集羣不可用；
•