MQ使用經驗

ActiveMQ是apache的一個開源JMS服務器，不只具有標準JMS的功能，還有不少額外的功能。公司裏引入ActiveMQ後，ActiveMQ成裏咱們公司業務系統中最重要的一個環節。全部應用都經過jms集成，若是ActiveMQ出了故障，整個系統就癱瘓了。所以，頭對ActiveMQ的性能，可靠性，以及如何正確使用，是很是的關心的，而我就被指派來作關於ActiveMQ的調研，本文對此作了些總結。

1 使用jms須要注意的問題

一下所述的問題，不只是對ActiveMQ，對於其餘的JMS也同樣有效。

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也有多種實現方式。它們的不一樣只是在共享數據和鎖機制上。
在ActiveMQ急羣中， broker有着Master和Slave兩種身份，其中，Slave至關於Master的熱備份，會一直複製Master的信息，當Master掛掉以後由最新複製Master的Slave接管。目前ActiveMQ官網給出如下三種方式實現Master和Salve之間纖細的複製：
a) 共享文件系統
b) 共享數據庫(JDBC)
c) 藉助Zookeeper（Replicated LevelDB Store）（這裏須要強調如下，在單機模式或者共享文件系統中，ActiveMQ會選擇使用KahaDB而不是LevelDB，官網說因levelDB不支持延遲或者計劃任務消息而被棄用)。

2.2.1 Pure master-slave

Pure master-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 JDBC master-slave

這種方式不須要特殊的配置，只要讓全部的節點都把數據存儲到同一個數據庫中。先拿到數據庫表的鎖的節點成爲master，一旦它失效了，其它的節點得到鎖，就能夠成爲master。由於數據經過數據庫共享，放在一個地方，不須要停機恢復master-slave。這種方式，須要額外的數據庫服務器，若是數據庫失效了，那麼就全失效了，並且速度不是很快。咱們在用mysql測試時，並無成功，master失效後，其餘的節點始終沒有升級成slave，多是數據庫配置的問題。

2.2.3 Share file master-slave

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

測試過衆多master-slave模式後發現，pure方式管理起來麻煩，jdbc方式成本高，效率低，share file方式須要高性能的共享文件，都有缺點。鑑於單臺activeMQ很可靠，而咱們的基礎平臺組願意用硬件備份，最終仍是決定不用master-slave了，也不用broker cluster，就用單臺，經過硬件冗餘保證數據不會丟失，並找另一臺刀片機作冷備，在主服務器失效時頂替。