ActiveMQ叢集理論概述

為什麼要對訊息中介軟體叢集？

1. 實現高可用，以排除單點故障引起的服務中斷
2. 實現負載均衡，以提升效率為更多客戶端提供服務

ActiveMQ叢集基礎知識

• 叢集方式：

  1. 客戶端叢集：讓多個消費者消費同一佇列（在佇列模式下訊息本身支援多個消費者負載，在主題模式下多個消費者消費的是完整的訊息，這將造成訊息重複的可能）
  2. Broker Clusters：通過多個Broker之間同步訊息以達到伺服器負載的可能
  3. Master Slave叢集：實現高可用（當主訊息伺服器宕機時，備用伺服器可以成為主服務代替）

• 客戶端配置

  • ActiveMQ失效轉移（failover） ActiveMQ提供失效轉移機制，用於客戶端創立連線時，它允許當一臺訊息伺服器宕機時，客戶端在傳輸層上重新連線到其他訊息伺服器。 語法：failover:(uri1,…,uriN)?transportOptions 說明：uri是訊息伺服器的地址 transporrtOptions傳輸引數說明：         randomize預設是true，表示在URI列表中選擇連線時是否採用隨機策略         initialReconnectDelay：預設是10，單位毫秒，表示第一次嘗試重連之間的等待時間        maxReconnectDelay：預設30000，單位毫秒，最長重連的時間間隔
  • Broker Cluster叢集配置 原理：        如下圖有兩個節點，節點A和節點B，節點A可以把訊息同步到節點B，節點B也可以把訊息同步到節點A，通過訊息同步之後，節點A接收到的訊息可以被節點B的消費者消費，節點B接收到的訊息也可以被節點A的消費者消費 圖片在git上 實現方式是採用NetworkConnector網路聯結器:        網路聯結器主要用於配置ActiveMQ伺服器與伺服器之間的網路通訊方式，用於伺服器透傳訊息        網路聯結器分為靜態聯結器和動態聯結器

靜態聯結器：是在配置中指定伺服器的具體ip資訊

<networkConnectors
 
>
    <networkConnector uri="static:(tcp://
127.0.0.1:61617,tcp://127.0.0.1:61618)"/>
</networkConnectors>

當我們伺服器比較多或者需要動態擴充套件的時候就可以採用動態聯結器。 動態連結器：使用多波的方式通知其他伺服器。配置如下(需要配置網路聯結器和傳輸聯結器）

<networkConnectors>
    <networkConnector uri="multicast://default:/>
</networkConnectors>

<transportConnectors>
    <transportConnector uri="
 
tcp://localhost:0" discoveryUri="multicast://default"/>
</transportConnectors>

傳輸聯結器中配置了一個發現的uri地址，這個就是主波地址，這樣就可以達到動態擴充套件伺服器的效果

Master/Slave叢集配置 叢集方案： 1 .沒有共享儲存的主備方案 share nothing storage master/slave(已過時，5.8+後移除，存在很多侷限性） 2. 共享儲存的主備方案 shared storage master/slave (此方案中節點獲取到訊息儲存排他鎖就可以成為master，而沒有獲取到資源鎖的節點將成為slave，當master待機的時候釋放資源鎖，而被slave獲取到後就成為了新的master，目前ActiveMQ支援基於san檔案系統和基於jdbc資料庫表級排他鎖的兩種方式) 3. 基於複製的LevelDB Store Replicated LevelDB Store(高可用儲存引擎)

       在使用共享儲存主備方案其實是使用了一些小伎倆來完成的Master/Slave, 不符合廣泛意義上的Master/Slave,而基於複製的LevelDB Store做到了這一點，這種方案主要使用zk來選舉Master，每個Broker將訊息儲存到本地，它們之間不共享任何資料，它們之間的資料同步通過zk來傳遞，用zk來保證叢集的穩定，這要求開發者至少部署三個broker，而zk本身也至少需要三臺伺服器來完成叢集才能保證zk自身的穩定性，如果不保證zk的穩定性，如果zk的叢集出現問題那我們整個伺服器叢集就蹦掉了

原理： 1. 共享儲存叢集的原理        有節點A和節點B兩臺伺服器，使用了一個共享的儲存地址稱之為持久化，它可以是jdbc的資料庫，也可以是基於san的檔案系統，然後將節點A和節點B的持久化配置都配置到同一個地方之後，先啟動節點A，這個時候它獲取到了資源排他鎖成為Master，再啟動節點B，這時候它獲取不到所資源成為了slave，成為了Master的伺服器就是獲取到了對外開放服務的能力，可以通過外部的客戶端提交資訊到節點A，但是不能傳送到節點B，如下圖：

       如果此時節點A掛掉，此時節點B立即獲取到持久化資源的排他鎖成為了新的Master，接收外部客戶端的請求，客戶端使用失效轉移之後將請求傳送到了B，完成了整個請求的不間斷性，達到了高可用的效果。 如下圖：

1. 基於複製的LevelDB Store的原理（因為它基於zk，所以至少要三臺伺服器）

   首先有三臺伺服器，分別是節點A，節點B，節點C，每個伺服器節點都有自己的儲存方式，因為配置了同一個zk節點，通過zk來選舉一臺伺服器作為Master，如下圖，假設選舉節點A作為Master，這時候節點A就具有了對外提供服務的能力，節點B和C不具備對外提供的能力，節點A獲取到外部服務的訊息資源之後他在本地儲存，然後通過zk把訊息同步給B和C，B和C分別在自己的伺服器上儲存，如果節點A出現故障，zk會立即重新選舉一臺Master

   兩種叢集方式的對比：

master/slave可以做到高可用，因為一臺伺服器掛掉之後另外一臺伺服器立即補充，保證了他的訊息不會丟失，但是做不了負載均衡，因為slave伺服器不具備外部提供服務的能力 Broker Cluster不具備高可用的能力，因為他自己的訊息並沒有在一個地方儲存， 換句話說就是當這臺伺服器掛掉之後，它正在處理的訊息會同步丟失。但是做到了負載均衡。

如何做到既可以具備高可用又能做到負載均衡呢？ 下面展示三臺伺服器的完美叢集方案： 有三個節點A,B,C,將節點A和節點B組成訊息同步，節點A和節點C組成訊息同步，節點B和節點C組成Master/Slave ,按順序啟動節點ABC。這個時候B獲取持久化的資源成為Master，C成為了Slave，A成了B的訊息同步伺服器，因為A 沒有持久化的配置，訊息將通過B完成持久化，A或者B接收的訊息都可以被負載消費，達成了負載均衡和高可用的要求。 分析：假設節點A掛掉，節點B還能繼續提供服務，整個叢集不受影響，當恢復了節點A之後，節點B上面的訊息可以被節點A消費，節點A上面新收到的訊息也能被節點B消費，叢集不受影響，假如節點B掛掉，節點C會獲取持久化資源成為新的Master，用來接受客戶端的請求，節點c可以持久化節點A和C上面的訊息，節點A和C也能負載訊息，節點B恢復之後，成為Slave等待資源鎖。整個叢集不受影響，符合高可用和負載均衡的要求，假如節點C掛掉，因為本身是Slave對叢集沒影響。 注意：當一臺伺服器掛掉之後要立即恢復，當兩臺伺服器一起宕機的時候叢集就崩掉了，所以要用更多的伺服器做到叢集的穩定。