消息中间件ActiveMQ与Kafka对比之ActiveMQ的介绍

问题导读
1.什么是ActiveMQ？
2.ActiveMQ有哪些特性？
3.什么是Kafka？







序言
今天让我们来谈谈身份高贵，举止优雅的消息中间件，主要还是浅谈，消息中间件这块水太深。大体上我们结合互联网业务做一些探讨，从互联网主要关心的消息安全性，服务器的稳定性容错性以及吞吐量三方面来讲。
由于这块产品非常多，我只挑选两个我使用过的产品结合使用经验做一些研究，他们是ActiveMQ和Kafka，前者完全实现了JMS的规范，后者看上去有一些“野路子”，并没有纠结于JMS规范，剑走偏锋的设计了另一套吞吐非常高的分布式发布-订阅消息系统，目前非常流行。接下来我们结合三个点（消息安全性，服务器的稳定性容错性以及吞吐量）来分别谈谈这两个消息中间件。我们先谈ActiveMQ。



1 血统纯正的ActiveMQ
AMQ是企业级应用的宠儿，Apache出品，完全遵循JMS规范，但是又非常的“重”，在互联网中它的性能令人诟病，目前（5.9版本），它依托Zookeeper和LevelDB支持主备failover切换及副本备份，但负载均衡还是不够完善……下面我们分话题来谈：
1）消息的安全性
在集群环境下，通过Zookeeper选出master，其余节点均为slave，只有master接受和处理客户端连接，其余slave节点均连接至master，并同步所有的持久化操作。（但是此种模式不支持延迟消息和计划消息，因为他们存储在KahaDB文件里。）如果master挂了，最后更新的slave将被选中当master。
并且，所有的消息操作需要集群一定节点(N/2+1)都操作成功才会返回操作成功的结果，如果是N=3个replicas节点，那么需要集群中有3/2+1=2个节点都确认操作成功。
所以如果结合JMS规范的ACK指令，消息的安全性在一个健康的集群中完全可以得到保障，三个节点的集群可以忍受1个节点挂掉仍可以提供服务。
2）服务的稳定容错性
客户端通过failover协议连接集群服务，所以AMQ的稳定性主要依赖于ZK和自身集群的节点状态，ZK集群的稳定性暂且不表，AMQ自身集群主要是通过公式(N/2+1)来计算，上一节已经谈到3个节点允许挂一个节点，看起来稳定性还是可以的，唯一担心的就是客户端的读写链接压力全部在master上。
3） 吞吐量
目前主备集群中所有的topic和queue的读写都在单节点的master上进行，所以吞吐量完全依赖单点master，看官网上AMQ是支持Broker clusters的，但是这个支持缺点很多，首先它依然采用failover协议，这看起来与主备集群冲突了，第二点如果其中一个broker挂了，那它所属的还没有被消费的消息将无法消费直到broker重启成功。
如果将Broker集群与主备集群结合起来倒是满足去除单点又达到负载均衡的需求，可惜两者都通过failover协议连接，目测需要改造后才能使用。

最后我们看两个AMQ的特性：
1）Virtual Topics
同一个应用上的一个topic订阅不能使用多个consumer来共同承担消息处理功能。因为每个consume都会获取所有消息，而且如果这个consume挂了，消息就无法被消费了，使用Virtual Topics可以实现消费端分组，实际上存储的时候是被转换成Queue的语义存储的。这样多个消费者可以同时消费同一个虚拟topic又不会收到全部的消息
2）Composite Destinations
这个特性的意义主要就是方便吧，可以同时发送一份消息至多个topic和多个queue，还可以使用filter去select某些消息的方向。具体参考官网文档吧。



2 性能怪兽Kafka
待更。。。
参考资料：
http://activemq.apache.org/replicated-leveldb-store.html
http://activemq.apache.org/clustering.html
http://activemq.apache.org/networks-of-brokers.html
http://my.oschina.net/u/719192/blog/293749
http://www.cnblogs.com/haippy/archive/2011/12/04/2276064.html
http://activemq.apache.org/virtual-destinations.html

赞！     

谢谢分享！！！！！