1.1?不要頻繁的建立和關閉連接

JMS使用長連接方式，一個程序，只要和JMS服務器保持一個連接就可以了，不要頻繁的建立和關閉連接。頻繁的建立和關閉連接，對程序的性能影響還是很大的。這一點和jdbc還是不太一樣的。

1.2 Connection的start()和stop()方法代價很高

JMS的Connection的start()和stop()方法代價很高，不能經常調用。我們試用的時候，寫了個jms的connection pool，每次將connection取出pool時調用start()方法，歸還時調用stop()方法，然而后來用jprofiler發現，一般的cpu時間都耗在了這兩個方法上。

1.3 start()后才能收消息

Connection的start()方法調用后，才能收到jms消息。如果不調用這個方法，能發出消息，但是一直收不到消息。不知道其它的jms服務器也是這樣。

1.4?顯式關閉Session

如果忘記了最后關閉Connection或Session對象，都會導致內存泄漏。這個在我測試的時候也發現了。本來以為關閉了Connection，由這個Connection生成的Session也會被自動關閉，結果并非如此，Session并沒有關閉，導致內存泄漏。所以一定要顯式的關閉Connection和Session。

1.5?對Session做對象池

對Session做對象池，而不是Connection。Session也是昂貴的對象，每次使用都新建和關閉，代價也非常高。而且后來我們發現，原來Connection是線程安全的，而Session不是，所以后來改成了對Session做對象池，而只保留一個Connection。

2?集群

ActiveMQ有強大而靈活的集群功能，但是使用起來還是會有很多陷阱。

2.1 broker cluster和?master-slave

ActiveMQ可以做broker的集群，也可以做master-slave方式的集群。前者能在多個broker之前fail-over和load-balance，但是在某個節點出故障時，可能導致消息丟失；而后者能實時備份消息，和fail-over，但是不能load-balance。broker cluser的方式，在一個broker上發送的消息可以在其它的broker上收到。當一個broker失效時，客戶端可以自動的轉到別的broker上運行，多個broker可以同時提供服務，但是消息只存儲在一個broker上，如果那個broker失效了，那么客戶端直到它重新啟動后才能收到該broker上的消息，假如很不幸，那個broker的存儲介質壞了，那么消息就丟失掉了。
Master-slave方式中，只有master提供服務，slave只是實時的備份master的數據，所以消息不會丟失。當master失效時，slave會自動升為master，客戶端會自動轉到slave上工作，所以能fail-over。由于只有master提供服務，所以不能將負載分到多個broker上。
其實單個broker的性能已經是相當的驚人了，在我們公司的機器上能達到每秒收發4000個消息，沒個消息4K字節這樣的速度，足夠公司目前的需要了，而公司并不希望丟失任何數據，所以我們選擇使用master-slave模式。

2.2?多種master-slave模式

master-slave也有多種實現方式。它們的不同只是在共享數據和鎖機制上。

2.2.1 Puremaster-slave

Puremaster-slave，顯示的在配置文件中指定一個broker做為另一個broker的slave。運行時，slave同過網絡自動從master出復制數據，同時在和master失去連接時自動升級為master。當master失效，slave成為master后，如果要讓原先的master重新投入運行，需要停掉運行中的slave(現在升級為master了)，手動復制slave中的數據到master中。再重新啟動master和slave。這種方式最簡單，效率也不錯，但是只能有兩臺做集群，只能fail-over一次，而且需要停機回復master-slave結構。

2.2.2 JDBCmaster-slave

這種方式不需要特殊的配置，只要讓所有的節點都把數據存儲到同一個數據庫中。先拿到數據庫表的鎖的節點成為master，一旦它失效了，其它的節點獲得鎖，就可以成為master。因為數據通過數據庫共享，放在一個地方，不需要停機恢復master-slave。這種方式，需要額外的數據庫服務器，如果數據庫失效了，那么就全失效了，而且速度不是很快。我們在用mysql測試時，并沒有成功，master失效后，其他的節點始終沒有升級成slave，可能是數據庫配置的問題。

2.2.3 Share filemaster-slave

這種方式類似于前者，也不需要特別的配置，只是通過共享文件系統來共享數據，靠文件鎖實現只有一臺成為master。共享文件系統的方式有很多，我們測試了nfs v4 (v3有bug，不行)，最終在穩定性，效率等方面不是很滿意，可能是通過網絡太慢了。

測試過眾多master-slave模式后發現，pure方式管理起來麻煩，jdbc方式成本高，效率低，share file方式需要高性能的共享文件，都有缺點。鑒于單臺activeMQ很可靠，而我們的基礎平臺組愿意用硬件備份，最終還是決定不用master-slave了，也不用broker cluster，就用單臺，通過硬件冗余保證數據不會丟失，并找另外一臺刀片機做冷備，在主服務器失效時頂替。

總結

以上是生活随笔為你收集整理的activemq的使用经验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。