原文地址：http://www.cnblogs.com/hapjin/p/5663024.html
一，ActiveMQ高可用性的架構
ActiveMQ的高可用性架構是基於Master/Slave 模型的。ActiveMQ總共提供了四種配置方案來配置HA，其中Shared Nothing Master/Slave 在5.8版本之后不再使用了，並在ActiveMQ5.9版本中引入了基於Zookeeper的Replicated LevelDB Store HA方案。
二，Master/Slave架構的配置解釋
①Shared Nothing Master/Slave 該架構最大的特點是：
1）Master 和 Slave各自都單獨存儲持久化的消息，它們不共享數據。
2）Master收到持久化消息時，需要先同步(sync)給Slave之后，才向Producer發送ACK確認。
3）只有Master負責Client的請求，Slave不接收Client請求。Slave連接到Master，負責備份消息。
4）Master出現故障，Slave有兩種處理方式：❶自己成為Master；❷關閉（停服務）---根據具體配置而定。
5）Master 與 Slave之間可能會出現“Split Brain”現象。比如：Master本身是正常的，但是Master與Slave之間的網絡出現故障，網絡故障導致Slave認為Master已經宕機，因為它自己會成為Master(根據配置：shutdownOnMasterFailure)。此時，對Client而言，就會存在兩個Master。
6）Slave 只能同步它連接到Master之后的消息。在Slave連接到Master之前Producer向Master發送的消息將不會同步給Slave，這可以通過配置（waitForSlave）參數，只有當Slave也啟動之后，Master才開始初始化TransportConnector接受Client的請求(Producer的請求)
7）如果Master 或者 Slave其中之一宕機，它們之間不同步的消息 無法 自動進行同步，此時只能手動恢復不同步的消息了。也就是說：“ActiveMQ沒有提供任何有效的手段，能夠讓master與slave在故障恢復期間，自動進行數據同步”
8）對於非持久化消息，並不會同步給Slave。因此，Master宕機，非持久化消息會丟失。
關於ShareNothing 高可用配置的一點理解：
❶由上面的第2)步可知：Producer向Master發消息之后，Master需要將消息同步給Slave之后，才向Producer返回確認ACK。因此，對Producer的響應有一定的延時。
如果為了保證快速響應，即Producer給Master發消息之后，Master收到了消息立即給Producer回復，然后再在后台把消息同步給Slave。這又會造成數據不一致性問題。
因為，如果Master收到了消息立即給Producer回復之后，Master還未來得及向Slave同步就宕機了，如果此條消息還在Master內存中，則Master宕機后消息就丟失了。如果Master收到Producer的消息，先寫入磁盤，然后再向Producer返回確認ACK，然后再在后台與Slave同步，那么Master就需要標記每條消息是否已經成功同步到了Slave，若消息還未同步到Slave，則Master重啟恢復后，需要立即同步Slave。只有當Slave成功同步了所有的Master上的消息之后，才能上線。這也無法實現 automatic failover。
關於一個很好的高可靠性解決方案：可參考 Hadoop HA中的QJM機制。其核心就是：1）采用集群，能容忍不超過大多數機器的失效；2）數據只寫大多數機器就返回確認，保證Client快速的響應能力；3）數據在后台在異步同步到集群所有的機器，從而保證高可用。
❷這里的Master--Slave機制中，只有一台Slave，並不是Slave集群(見上面結構圖)。Master宕機，或者Slave宕機后，都會給整個服務造成極大的風險，並沒有像Hadoop HA中的那樣能夠容忍“不超過大多數機器失效”的保證，即沒有做到真正的高可用性。
❸還可能出現“雙主”問題。即上面提到的“Split Brian”現象。
②Shared Database Master/Slave
這是很常用的一種架構。“共享存儲”，意味着Master與Slave之間的數據是共享的。
那如何避免沖突呢？通過爭奪數據庫表的排他鎖，只有Master有鎖，未獲得鎖的自動成為Slave。
ActiveMQ Message Broker uses a relational database, it grabs an exclusive lock on a table ensuring that no other ActiveMQ broker can access the database at the same time
對於“共享存儲”而言，只會“共享”持久化消息。對於非持久化消息，它們是在內存中保存的。可以通過配置（forcePersistencyModeBrokerPlugin persistenceFlag）屬性強制所有的消息都持久化。
當Master宕機后，Slave可自動接管服務成為Master。由於數據是共享的，因此Master和Slave之間不需要進行數據的復制與同步。Slave之間通過競爭鎖來決定誰是Master。
③Shared File system Master/Slave
這種方式和共享數據庫存儲原理基本一樣，（文件系統也有文件鎖），故不詳細介紹。
The elected master broker node starts and accepts client connections.
The other nodes go into slave mode and connect the the master and synchronize their persistent state /w it.
以上也表明：每個Broker都是單獨存儲數據的。因為Master要把新的數據復制到Slave上。從這個角度看：稱這種方式為“Share Storage”有點不合適。
2）Quorum機制的又一應用
假設有3個Broker，那么選舉時至少需要兩個Broker同意（大多數）之后，才能選出Master。此外，只需要當新消息復制到大多數Broker上時，就可以給Producer返回ACK。其他少數Broker則可以在后台以異步方式復制新的消息。
All messaging operations which require a sync to disk will wait for the update to be replicated to a quorum of the nodes before completing.
So if you configure the store with replicas="3" then the quorum size is (3/2+1)=2.
The master will store the update locally and wait for 1 other slave to store the update before reporting success.
比如說：一共有3個Broker，一個Master，二個Slave。當新消息到達Master時，Master需要將消息同步到其中一台Slave之后，才能向Producer發送ACK確認此次消息成功發送。
而剩下的另一台Slave，則可以在后台以異步方式復制這個新消息。此外，還能容忍一台Slave宕機。（能容忍不超過大多數的Broker宕機）
這種設計要求，可以保證集群中消息的可靠性，只有當(replicas/2 + 1)個節點物理故障，才會有丟失消息的風險。另外，也提高了一定的響應性，因為它不需要將消息同步到所有的Slave上，而只需要同步到大多數Broker上。
三，參考資料
https://activemq.apache.org/artemis/docs/1.0.0/ha.html
Replicated LevelDB Store HA官方文檔