ActiveMQ的集群方式綜述
ActiveMQ的集群方式主要由兩種：Master-Slave和Broker Cluster
Master-Slave
Master-Slave方式中，只能是Master提供服務(wù)慨仿，Slave是實時地備份Master的數(shù)據(jù)蹄梢，以保證消息的可靠性。當(dāng)Master失效時，Slave會自動升級為Master刊咳，客戶端會自動連接到Slave上工作秘遏。Master-Slave模式分為四類：Pure Master Slave、Shared File System Master Slave和JDBC Master Slave鹿寻，以及Replicated LevelDB Store方式 睦柴。
Master-Slave方式都不支持負(fù)載均衡，但可以解決單點故障的問題毡熏，以保證消息服務(wù)的可靠性坦敌。
Broker Cluster
Broker Cluster主要是通過network of Brokers在多個ActiveMQ實例之間進(jìn)行消息的路由。Broker Cluster模式支持負(fù)載均衡痢法，可以提高消息的消費能力狱窘，但不能保證消息的可靠性。所以為了支持負(fù)載均衡财搁，同時又保證消息的可靠性蘸炸，我們往往會采用Msater-Slave+Broker Cluster的模式。
注意：
以下的測試均在一臺機器上進(jìn)行尖奔，為避免多個ActiveMQ****之間在啟動時發(fā)生端口沖突搭儒，需要修改每個ActiveMQ****的配置文件中MQ****的服務(wù)端口。如果實際部署在不同的機器提茁，端口的修改是不必要的淹禾。
Pure Master Slave方式
ActiveMQ5.8以前支持，自從Activemq5.8開始茴扁，Activemq的集群實現(xiàn)方式取消了傳統(tǒng)的Pure Master Slave方式铃岔，并從Activemq5.9增加了基于zookeeper+leveldb的實現(xiàn)方式。
[圖片上傳失敗...(image-9d56e8-1553515192235)]
使用兩個ActiveMQ服務(wù)器峭火，一個作為Master毁习，Master不需要做特殊的配置智嚷；另一個作為Slave，配置activemq.xml文件纺且，在<broker>節(jié)點中添加連接到Master的URI和設(shè)置Master失效后不關(guān)閉Slave纤勒。具體配置參考頁面：http://activemq.apache.org/pure-master-slave.html
Shared File System Master Slave方式
就是利用共享文件系統(tǒng)做ActiveMQ集群，是基于ActiveMQ的默認(rèn)數(shù)據(jù)庫kahaDB完成的隆檀，kahaDB的底層是文件系統(tǒng)摇天。這種方式的集群，Slave的個數(shù)沒有限制恐仑，哪個ActiveMQ實例先獲取共享文件的鎖泉坐，那個實例就是Master，其它的ActiveMQ實例就是Slave裳仆，當(dāng)當(dāng)前的Master失效腕让，其它的Slave就會去競爭共享文件鎖，誰競爭到了誰就是Master歧斟。這種模式的好處就是當(dāng)Master失效時不用手動去配置纯丸，只要有足夠多的Slave。
如果各個ActiveMQ實例需要運行在不同的機器静袖，就需要用到分布式文件系統(tǒng)了觉鼻。
Shared JDBC Master Slave
JDBC Master Slave模式和Shared File Sysytem Master Slave模式的原理是一樣的，只是把共享文件系統(tǒng)換成了共享數(shù)據(jù)庫队橙。我們只需在所有的ActiveMQ的主配置文件中activemq.xml添加數(shù)據(jù)源坠陈，所有的數(shù)據(jù)源都指向同一個數(shù)據(jù)庫。
然后修改持久化適配器捐康。這種方式的集群相對Shared File System Master Slave更加簡單仇矾，更加容易地進(jìn)行分布式部署，但是如果數(shù)據(jù)庫失效解总，那么所有的ActiveMQ實例都將失效贮匕。
配置修改清單
1、開啟網(wǎng)絡(luò)監(jiān)控功能（useJmx="true"）
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" dataDirectory="${activemq.data}" useJmx="true">
2花枫、數(shù)據(jù)庫持久化配置刻盐，注釋掉之前kahadb消息存儲器
<persistenceAdapter>
<jdbcPersistenceAdapter dataDirectory="${activemq.data}" dataSource="#mysql-ds" createTablesOnStartup="false" useDatabaseLock="true"/>
</persistenceAdapter>
3、增加數(shù)據(jù)源mysql-ds
4乌昔、修改客戶端上連接url為類似于failover:(tcp://0.0.0.0:61616,tcp://0.0.0.0:61617,tcp://0.0.0.0:61618)?randomize=false
注：默認(rèn)情況下隙疚，failover機制從URI列表中隨機選擇出一個URI進(jìn)行連接，這可以有效地控制客戶端在多個broker上的負(fù)載均衡磕道，但是，要使客戶端首先連接到主節(jié)點行冰，并在主節(jié)點不可用時只連接到輔助備份代理溺蕉，需要設(shè)置randomize = false伶丐。
5、可以看到只有一臺MQ成為Master疯特，其余兩臺成為slave并會嘗試成為Master哗魂，并不斷重試。且兩臺slave的管理控制臺將無法訪問漓雅。
測試方法
先啟動生產(chǎn)者录别，發(fā)送幾條消息啟動消費者，可看到接收到的消息關(guān)閉消費者生產(chǎn)者繼續(xù)發(fā)送幾條消息-消息A停止broker01（可看到生產(chǎn)者端顯示連接到broker02（tcp://0.0.0.0:61617）了邻吞，同時運行broker02的Shell也顯示其成為了Master）生產(chǎn)者繼續(xù)發(fā)送幾條消息-消息B啟動消費者消費者接收了消息A和消息B组题，可見broker02接替了broker01的工作，而且儲存了之前生產(chǎn)者經(jīng)過broker01發(fā)送的消息關(guān)閉消費者生產(chǎn)者繼續(xù)發(fā)送幾條消息-消息C停止broker02（可看到生產(chǎn)者端顯示連接到broker03（tcp://0.0.0.0:61618）了抱冷，同時運行broker03的Shell也顯示其成為了Master）生產(chǎn)者繼續(xù)發(fā)送幾條消息-消息D啟動消費者消費者接收了消息C和消息D崔列，可見broker03接替了broker02的工作，而且儲存了之前生產(chǎn)者經(jīng)過broker02發(fā)送的消息再次啟動broker01旺遮，生產(chǎn)者或消費者均未顯示連接到broker01(tcp://0.0.0.0:61616)赵讯，表明broker01此時只是個Slave
Replicated LevelDB Store
ActiveMQ5.9以后才新增的特性，使用ZooKeeper協(xié)調(diào)選擇一個node作為master耿眉。被選擇的master broker node開啟并接受客戶端連接边翼。 其他node轉(zhuǎn)入slave模式，連接master并同步他們的存儲狀態(tài)鸣剪。slave不接受客戶端連接讯私。所有的存儲操作都將被復(fù)制到連接至Master的slaves。
如果master死了西傀，得到了最新更新的slave被允許成為master斤寇。推薦運行至少3個replica nodes。
配置修改清單
1拥褂、 使用性能比較好的LevelDB替換掉默認(rèn)的KahaDB
<persistenceAdapter>
<replicatedLevelDB
directory="${activemq.data}/leveldb"
replicas="3"
bind="tcp://0.0.0.0:62623"
zkAddress="127.0.0.1:2181"
hostname="localhost"
zkPath="/activemq/leveldb-stores"/>
</persistenceAdapter>
配置項說明：
- directory：持久化數(shù)據(jù)存放地址
- replicas：集群中節(jié)點的個數(shù)
- bind：集群通信端口
- zkAddress：ZooKeeper集群地址
- hostname：當(dāng)前服務(wù)器的IP地址娘锁，如果集群啟動的時候報未知主機名錯誤，那么就需要配置主機名到IP地址的映射關(guān)系饺鹃。
- zkPath：ZooKeeper數(shù)據(jù)掛載點
2莫秆、修改客戶端上連接url為failover:(tcp://0.0.0.0:61616,tcp://0.0.0.0:61617,tcp://0.0.0.0:61618)?randomize=false
3、可以看到只有一臺MQ成為Master悔详，其余兩臺成為slave镊屎。且兩臺slave的管理控制臺將無法訪問。
LevelDB解釋
Leveldb是一個google實現(xiàn)的非常高效的kv數(shù)據(jù)庫茄螃，目前的版本1.2能夠支持billion級別的數(shù)據(jù)量了缝驳。 在這個數(shù)量級別下還有著非常高的性能，采用單進(jìn)程的服務(wù)，性能非常之高用狱，在一臺4核Q6600的CPU機器上运怖，每秒鐘寫數(shù)據(jù)超過40w，而隨機讀的性能每秒鐘超過10w夏伊。由此可以看出摇展，具有很高的隨機寫，順序讀/寫性能溺忧，但是隨機讀的性能很一般咏连，也就是說，LevelDB很適合應(yīng)用在查詢較少鲁森，而寫很多的場景祟滴。LevelDB應(yīng)用了LSM (Log Structured Merge) 策略，通過一種類似于歸并排序的方式高效地將更新遷移到磁盤刀森，降低索引插入開銷踱启。
限制：1、非關(guān)系型數(shù)據(jù)模型（NoSQL）研底，不支持sql語句埠偿，也不支持索引；2榜晦、一次只允許一個進(jìn)程訪問一個特定的數(shù)據(jù)庫冠蒋；3、沒有內(nèi)置的C/S架構(gòu)乾胶，但開發(fā)者可以使用LevelDB庫自己封裝一個server抖剿；
測試方法
同Shared JDBC Master Slave 測試方法
