这是两种截然不同的mq。Active MQ被称为“传统”mq。所谓“传统”是指，他要支持一些标准接口，比如AMQP, STOMP等需要维护consumer的状态。即当前consumer读到哪个数据了，是active mq来维护的。active mq最早用来做企业级别的系统整合。要支持所谓的“企业级队列模式“，但请原谅我搞到最后也没理解这个企业级到底怎么企业级了，也许现在的大多数企业早已不像10多年前那样设计系统了？active mq因为支持XA协议，所以可以和JDBC一起实现2PC分布式事务，但我基本没见过有人这么用，大概是因为太慢和太难维护的原因。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，客户端自动重连，自动去重等）

喜欢小编就关注小编吧！