摘自：http://blog.csdn.net/m13321169565/article/details/8081314
1.1 不要頻繁的建立和關閉連接
JMS使用長連接方式，一個程序，只要和JMS服務器保持一個連接就可以了，不要頻繁的建立和關閉連接。頻繁的建立和關閉連接，對程序的性能影響還是很大的。這一點和jdbc還是不太一樣的。
1.2 Connection的start()和stop()方法代價很高
JMS的Connection的start()和stop()方法代價很高，不能經常調用。我們試用的時候，寫了個jms的connection pool，每次將connection取出pool時調用start()方法，歸還時調用stop()方法，然而后來用jprofiler發現，一般的cpu時間都耗在了這兩個方法上。
Connection的start()方法調用后，才能收到jms消息。如果不調用這個方法，能發出消息，但是一直收不到消息。不知道其它的jms服務器也是這樣。
如果忘記了最后關閉Connection或Session對象，都會導致內存泄漏。這個在我測試的時候也發現了。本來以為關閉了Connection，由這個Connection生成的Session也會被自動關閉，結果並非如此，Session並沒有關閉，導致內存泄漏。所以一定要顯式的關閉Connection和Session。
對Session做對象池，而不是Connection。Session也是昂貴的對象，每次使用都新建和關閉，代價也非常高。而且后來我們發現，原來Connection是線程安全的，而Session不是，所以后來改成了對Session做對象池，而只保留一個Connection。
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模式。
master-slave也有多種實現方式。它們的不同只是在共享數據和鎖機制上。
Puremaster-slave，顯示的在配置文件中指定一個broker做為另一個broker的slave。運行時，slave同過網絡自動從master出復制數據，同時在和master失去連接時自動升級為master。當master失效，slave成為master后，如果要讓原先的master重新投入運行，需要停掉運行中的slave(現在升級為master了)，手動復制slave中的數據到master中。再重新啟動master和slave。這種方式最簡單，效率也不錯，但是只能有兩台做集群，只能fail-over一次，而且需要停機回復master-slave結構。
這種方式不需要特殊的配置，只要讓所有的節點都把數據存儲到同一個數據庫中。先拿到數據庫表的鎖的節點成為master，一旦它失效了，其它的節點獲得鎖，就可以成為master。因為數據通過數據庫共享，放在一個地方，不需要停機恢復master-slave。這種方式，需要額外的數據庫服務器，如果數據庫失效了，那么就全失效了，而且速度不是很快。我們在用mysql測試時，並沒有成功，master失效后，其他的節點始終沒有升級成slave，可能是數據庫配置的問題。
這種方式類似於前者，也不需要特別的配置，只是通過共享文件系統來共享數據，靠文件鎖實現只有一台成為master。共享文件系統的方式有很多，我們測試了nfs v4 (v3有bug，不行)，最終在穩定性，效率等方面不是很滿意，可能是通過網絡太慢了。
測試過眾多master-slave模式后發現，pure方式管理起來麻煩，jdbc方式成本高，效率低，share file方式需要高性能的共享文件，都有缺點。鑒於單台activeMQ很可靠，而我們的基礎平台組願意用硬件備份，最終還是決定不用master-slave了，也不用broker cluster，就用單台，通過硬件冗余保證數據不會丟失，並找另外一台刀片機做冷備，在主服務器失效時頂替。