ActiveMQ是apache的一個開源JMS服務(wù)器，不僅具備標(biāo)準(zhǔn)JMS的功能，還有很多額外的功能。公司里引入ActiveMQ后，ActiveMQ成里我們公司業(yè)務(wù)系統(tǒng)中最重要的一個環(huán)節(jié)。所有應(yīng)用都通過jms集成，如果ActiveMQ出了故障，整個系統(tǒng)就癱瘓了。因此，頭對ActiveMQ的性能，可靠性，以及如何正確使用，是非常的關(guān)心的，而我就被指派來做關(guān)于ActiveMQ的調(diào)研，本文對此做了些總結(jié)。
1 使用jms需要注意的問題
一下所述的問題，不僅是對ActiveMQ，對于其他的JMS也一樣有效。
1.1 不要頻繁的建立和關(guān)閉連接
JMS使用長連接方式，一個程序，只要和JMS服務(wù)器保持一個連接就可以了，不要頻繁的建立和關(guān)閉連接。頻繁的建立和關(guān)閉連接，對程序的性能影響還是很大的。這一點和jdbc還是不太一樣的。
1.2 Connection的start()和stop()方法代價很高
JMS的Connection的start()和stop()方法代價很高，不能經(jīng)常調(diào)用。我們試用的時候，寫了個jms的connection pool，每次將connection取出pool時調(diào)用start()方法，歸還時調(diào)用stop()方法，然而后來用jprofiler發(fā)現(xiàn)，一般的cpu時間都耗在了這兩個方法上。
1.3 start()后才能收消息
Connection的start()方法調(diào)用后，才能收到j(luò)ms消息。如果不調(diào)用這個方法，能發(fā)出消息，但是一直收不到消息。不知道其它的jms服務(wù)器也是這樣。
1.4 顯示關(guān)閉Session
如果忘記了最后關(guān)閉Connection或Session對象，都會導(dǎo)致內(nèi)存泄漏。這個在我測試的時候也發(fā)現(xiàn)了。本來以為關(guān)閉了Connection，由這個Connection生成的Session也會被自動關(guān)閉，結(jié)果并非如此，Session并沒有關(guān)閉，導(dǎo)致內(nèi)存泄漏。所以一定要顯示的關(guān)閉Connection和Session。
1.5 對Session做對象池
對Session做對象池，而不是Connection。Session也是昂貴的對象，每次使用都新建和關(guān)閉，代價也非常高。而且后來我們發(fā)現(xiàn)，原來Connection是線程安全的，而Session不是，所以后來改成了對Session做對象池，而只保留一個Connection。
2 集群
ActiveMQ有強大而靈活的集群功能，但是使用起來還是會有很多陷阱。
2.1 broker cluster和 master-slave
ActiveMQ可以做broker的集群，也可以做master-slave方式的集群。前者能在多個broker之前fail-over和load-balance，但是在某個節(jié)點出故障時，可能導(dǎo)致消息丟失；而后者能實時備份消息，和fail-over，但是不能load-balance。broker cluser的方式，在一個broker上發(fā)送的消息可以在其它的broker上收到。當(dāng)一個broker失效時，客戶端可以自動的轉(zhuǎn)到別的broker上運行，多個broker可以同時提供服務(wù)，但是消息只存儲在一個broker上，如果那個broker失效了，那么客戶端直到它重新啟動后才能收到該broker上的消息，假如很不幸，那個broker的存儲介質(zhì)壞了，那么消息就丟失掉了。
Master-slave方式中，只有master提供服務(wù)，slave只是實時的備份master的數(shù)據(jù)，所以消息不會丟失。當(dāng)master失效時，slave會自動升為master，客戶端會自動轉(zhuǎn)到slave上工作，所以能fail-over。由于只有master提供服務(wù)，所以不能將負載分到多個broker上。
其實單個broker的性能已經(jīng)是相當(dāng)?shù)捏@人了，在我們公司的機器上能達到每秒收發(fā)4000個消息，沒個消息4K字節(jié)這樣的速度，足夠公司目前的需要了，而公司并不希望丟失任何數(shù)據(jù)，所以我們選擇使用master-slave模式。
2.2 多種master-slave模式
master-slave也有多種實現(xiàn)方式。它們的不同只是在共享數(shù)據(jù)和鎖機制上。
2.2.1 Pure master-slave
Pure master-slave，顯示的在配置文件中指定一個broker做為另一個broker的slave。運行時，slave同過網(wǎng)絡(luò)自動從master出復(fù)制數(shù)據(jù)，同時在和master失去連接時自動升級為master。當(dāng)master失效，slave成為master后，如果要讓原先的master重新投入運行，需要停掉運行中的slave(現(xiàn)在升級為master了)，手動復(fù)制slave中的數(shù)據(jù)到master中。再重新啟動master和slave。這種方式最簡單，效率也不錯，但是只能有兩臺做集群，只能fail-over一次，而且需要停機回復(fù)master-slave結(jié)構(gòu)。
2.2.2 JDBC master-slave
這種方式不需要特殊的配置，只要讓所有的節(jié)點都把數(shù)據(jù)存儲到同一個數(shù)據(jù)庫中。先拿到數(shù)據(jù)庫表的鎖的節(jié)點成為master，一旦它失效了，其它的節(jié)點獲得鎖，就可以成為master。因為數(shù)據(jù)通過數(shù)據(jù)庫共享，放在一個地方，不需要停機恢復(fù)master-slave。這種方式，需要額外的數(shù)據(jù)庫服務(wù)器，如果數(shù)據(jù)庫失效了，那么就全失效了，而且速度不是很快。我們在用mysql測試時，并沒有成功，master失效后，其他的節(jié)點始終沒有升級成slave，可能是數(shù)據(jù)庫配置的問題。
2.2.3 Share file master-slave
這種方式類似于前者，也不需要特別的配置，只是通過共享文件系統(tǒng)來共享數(shù)據(jù)，靠文件鎖實現(xiàn)只有一臺成為master。共享文件系統(tǒng)的方式有很多，我們測試了nfs v4 (v3有bug，不行)， 最終在穩(wěn)定性，效率等方面不是很滿意，可能是通過網(wǎng)絡(luò)太慢了。
測試過眾多master-slave模式后發(fā)現(xiàn)，pure方式管理起來麻煩，jdbc方式成本高，效率低，share file方式需要高性能的共享文件，都有缺點。鑒于單臺activeMQ很可靠，而我們的基礎(chǔ)平臺組愿意用硬件備份，最終還是決定不用master-slave了，也不用broker cluster，就用單臺，通過硬件冗余保證數(shù)據(jù)不會丟失，并找另外一臺刀片機做冷備，在主服務(wù)器失效時頂替。
相關(guān)文章:
