ActiveMQ 和 Kafka 有什么区别？

转自：https://www.zhihu.com/question/272186518

这是两种截然不同的mq。

Active MQ被称为“传统”mq。所谓“传统”是指，

1. 他要支持一些标准接口，比如AMQP, STOMP等
2. 需要维护consumer的状态。即当前consumer读到哪个数据了，是active mq来维护的。
3. active mq最早用来做企业级别的系统整合。要支持所谓的“企业级队列模式“，但请原谅我搞到最后也没理解这个企业级到底怎么企业级了，也许现在的大多数企业早已不像10多年前那样设计系统了？
4. active mq因为支持XA协议，所以可以和JDBC一起实现2PC分布式事务，但我基本没见过有人这么用，大概是因为太慢和太难维护的原因。
5. active mq支持对事物处理的commit（自动+手动），但是如果你理解分布式一致性的话就能明白单一系统能够commit还是无法满足一致性的要求

其实我看到过有人用它，完全是因为他是java这个圈子里第一个广泛被使用的mq（之后又有rabbit mq），是一种习惯。

而Kakfa一开始被设计就是以高吞吐+高性能+HA来实现的。我的压测显示Kafka的吞吐量大概高于active mq两个数量级。即使Kafka配置了全同步的复制，也会比Active MQ高5～6倍。

Kafka的核心设计是append log file。即不断追加写log文件来实现消息数据的写入（对比一下，active mq的内部更偏向一个传统数据库，不过active mq最近的版本开始用level db）。磁盘追加写的性能要远高于随机写。Kafka允许consumer自己维护自己读取到了的位置，还允许随时调整这个位置做“message replay”。

Kafka围绕topic和partition的模型解决了message的分发和HA的问题，并且能够通过配置来支持全异步，半同步，全同步的复制。

最近Kafka提供了一个新的Stream API，顺便还支持了事务（但限制在数据处理这个步骤）

总体来讲Kafka特别适合的场景是实时数据分析，log分析等场景。但是如果用来做业务事件的分发，也非常适合。

如果业务场景压力不大，又比较传统，需要那些老的message协议，用Active MQ完全够用，但同时也可以考虑一下同类的Rabbit MQ；但是如果吞吐量的要求很大，那么Kafka几乎可能是自研之外，非常理想的选择了。。

----- 更新一下 ----

回答一下Kafka的缺点和不适合的场景。

说实话，我并没有发现Kafka本身有什么明显的短板。如果倒退几年，Kafka 0.7，0.8版本的年代，也许可以说他缺一些功能，比如认证，SSL端端加密，比较好用的管理运维工具等等；这个比起Active MQ 10+年历史上积累的工具差很多。但是Kafka的最新版本已经补上了这些问题，各种功能工具都逐渐完备了。

如果非得说Kafka有啥缺点，可能就是运维略复杂。你可能需要安装很多组件，还要调整一些OS系统参数来对Kafka进行调优。一些好处（比如message replay）需要额外的开发。一些一致性上的把控，kafka选择把底层的一些细节暴露出来，由集成的开发者来把控。不能做到拆箱即用。对于小团队，这样的运维成本有些高。但对于一个高性能系统，这些工作是天经地义的事情。

另外Kafka并不支持Java的那些“标准messaging”协议，所以如果应用场景一定要用到这些标准，那么只能和Kafka说拜拜。（但这里一定要吐一下槽，那些标准协议除了一层层的抽象，根本就没能解决messaging系统里的很多实际的问题。但是Kafka的确解决了那些问题，比如HA，客户端自动重连，自动去重等）

============================================================================

目前我们公司同时在用amq和kafka两种产品。但是也定下了以kafka为主，amq为辅的路线。

就像第一个回答所说，amq是一个专门针对消息场景的mq，而kafka现在的发展趋势主要是流数据处理平台。

amq的优势是功能全，安装简单，需要的资源比kafka少，两台amq就能满足服务高可用。坏处是性能较低，但是这也是看场景的。曾经尝试过将amq调整成纯内存模式，单台4C8G的服务器配4GJVM性能就能达到6w TPS。此外amq目前版本是5.15，而在5.11前的版本支持jdk1.6，对一些仍在使用jdk1.6的应用做分布式迁移时仍然可以使用主要功能。

还有个主要优势就是协议支持得太全了，包括mqtt,amqp,stormp全都支持，简直万能。

 

kafka是一个性能怪兽，简单配置就轻松可以达到10w TPS。而且不像市面上其它mq一样以broker为维度做高可用，而是以topic和partition，这样就不会有备机特别闲的问题。但是kafka的主要问题有以下几个：

1. 对zk的依赖，zk一直有超半数节点宕机就宕的问题，这个问题导致了zk的部署必须非常小心。

2. 对消息服务功能方面的支持不如其它mq那么好，比如协议支持的不足，消息延迟投递功能的缺失，消息选择器功能的不足等等。消费者横向扩容更是需要人工增加partition数量。

3. 同等资源条件下和amq比较，能创建的topic数量远低于amq。这也制约了大量队列的场景。

之前和别的公司交流过，他们为了让kafka能满足他们对消息服务的需求，甚至在每一个kafka组件前设置了一个自己写的不同功能的前置服务器。比如消费者和broker之间，生产者和broker之间，broker和zk之间等等

 

非利益相关，如果需要考虑和kafka类似的专注于消息服务领域的产品，可以看看阿里开源的RocketMQ，更侧重于mq领域。