ActiveMQ使用經驗與最佳化

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，就用單台，通過硬體冗餘保證資料不會丟失，並找另外一台刀片機做冷備，在主伺服器失效時頂替。