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系统