ActiveMQ學習筆記07 - 優缺點

優勢：

能夠用JDBC

雖然使用JDBC會下降ActiveMQ的性能，可是數據庫一直都是開發人員最熟悉的存儲介質。將消息存到數據庫，看得見摸得着。並且公司有專門的DBA去對數據庫進行調優，主從分離。

監控完善

擁有完善的監控，包括Web Console，JMX，Shell命令行，Jolokia的REST API。應有盡有，對於一個7*24的產品，沒有監控就不能上線。

界面友善

提供的Web Console能夠知足大部分狀況，還有不少第三方的組件可使用，如hawtio。

支持JMS

支持JMS的統一接口，可使用Sprinig的JmsTemplate提高開發效率。

推送模式

Broker推送消息到Consumer，消息實時性高。

不丟消息

支持基於XA的事務。

有安全機制

支持基於shiro，jaas等多種安全配置機制，能夠對Queue/Topic進行認證和受權。

Queue支持高可用和分片

使用Exclusive Consumer能夠實現Queue的高可用，使用Message Group能夠實現Queue的高可用加消息分片。

Broker支持數據複製

可使用基於數據庫的主從複製，或者基於Level DB的複製實現數據的高可用。

缺點：

Broker不支持消息分片

沒有像Kafka那樣提供消息分片寫入Broker的功能，不能實現動態擴展Broker。

Topic不支持高可用和分片

基於Exclusive Consumer和Message Group，只能在Queue上起做用。

能夠把Topic轉成Queue，以支持高可用和分片，可是數據爆炸

使用Virtual Topic能夠將Topic轉成Queue，可是每一個訂閱者會複製一份消息到Queue，使Broker的存儲空間爆發式增加。詳細內容可參考ActiveMQ學習筆記06 - 消費者負載均衡與高可用中Virtual Topics。

基於LevelDb高可用，必須至少使用3臺機器，形成資源浪費

LevelDb使用Zookeeper做爲調度中心，經常使用的配置是1臺主機，2臺備機，並且2臺備機不提供服務。形成資源浪費。並且一旦有2臺機器死機，雖然仍然有一臺機器存活，可是仍然不能提供服務。

適用場景：

只有在須要強一致性事務時須要使用ActiveMQ。使用JDBC的存儲形式，這樣一旦出錯，整個數據庫回滾。其餘的文件存儲機制，無論是levedb仍是kahadb，都是雞肋，提升了性能，可是不能徹底保證事務一致性。若是考慮性能問題，可使用kafka，metaq。最佳實踐是：使用jdbc存儲，master-slave方式備份數據，static靜態集羣的方式高可用，同時知足服務和數據的高可用。若是須要，自行開發數據分片功能。

典型場景：交易，內部oa系統