常用消息队列rocketmq、rabbitmq、kafka、activemq对比

rocketmq、rabbitmq、kafka、activemq对比

​ 随着互联网“微架构”模式兴起，原有大型集中式的IT服务被分拆成细粒度的多个“微服务”，这些微服务可以在一个局域网内，也可能跨机房部署。一方面对服务之间松耦合的要求越来越高，另一方面，服务之间的联系却越来越紧密，对通信质量的要求也越来越高。分布式消息队列可以提供应用解耦、流量消峰、消息分发等功能，已经成为大型互联网服务架构里标配的中间件。

1. 知名的消息引擎

1. ZeroMQ
2. 推特的Distributedlog
3. ActiveMQ：Apache旗下的老牌消息引擎
4. RabbitMQ、Kafka：AMQP的默认实现。
5. RocketMQ ：阿里开源
6. Artemis：Apache的ActiveMQ下的子项目
7. Apollo：同样为Apache的ActiveMQ的子项目的号称下一代消息引擎
8. IronMQ: 商业化的消息引擎
9. OpenMQ: 实现了JMS(Java Message Service)标准

2.Kafka、RocketMQ、RabbitMQ比较

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
开发语言	java	erlang	java	scala
单机吞吐量	万级	万级	10万级	10万级(经优化可达百万级)
时效性	ms级	us级	ms级	ms级
可用性	高（主从架构）	高（主从架构）	非常高（分布式架构）	非常高（分布式架构）
可靠性	较低概率丢失	不丢失	不丢失	不丢失
优点	产品成熟度高	1. 由于erlang语言的特性，mq 性能较好，高并发； 2. 吞吐量到万级，MQ功能比较完备; 3. 健壮、稳定、易用、跨平台、支持多种语言、文档齐全； 4. 开源提供的管理界面功能完善， 社区活跃度高；	1. 单机吞吐量：十万级 2. 可用性：非常高，分布式架构 3. 消息可靠性：经过参数优化配置，消息可以0丢失 4. 功能支持：MQ功能较为完善，分布式架构，扩展性好 5. 支持10亿级别的消息堆积，不会因为堆积导致性能下降 6.源码由java编写，阅读与定制相对容易	1.吞吐量高，单机写入TPS约在百万条/秒 2.可用性常高，分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
缺点	官方社区现在对ActiveMQ 5.x维护越来越少	1. erlang开发，很难去看懂源码，依赖于开源社区的快速维护和修复bug，不利于做二次开发和维护； 2. RabbitMQ吞吐量相对较低，实现机制比较重。 3. 需要学习比较复杂的接口和协议，学习和维护成本较高。	支持的客户端语言不多，目前是java及c++，其中c++不成熟；	1.功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用 2.Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长 3. 使用短轮询方式，实时性取决于轮询间隔时间； 4. 消费失败不支持重试； 5. 支持消息顺序，但是一台代理宕机后，就会产生消息乱序； 6. 社区更新较慢；

3. 消息队列选择建议

1.Kafka

Kafka基于Pull的模式来处理消息消费，追求高吞吐量，项目之初就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。

所以有诸如日志采集功能等之类的功能，首选kafka。

2.RocketMQ

历经阿里双11多次考验，RoketMQ在稳定性上可能更值得信赖。

所以有较高可靠性要求的需求，而且项目以java为主要开发语言，可以选择RocketMQ。

3.RabbitMQ

RabbitMQ :结合erlang语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护。不过，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug。

3. RocketMQ管理后台

通过以上对比，我们选用RocketMQ作用系统的消息中间件。

RocketMQ-Console是RocketMQ项目的扩展插件，是一个图形化管理控制台，提供Broker集群状态查看，Topic管理，Producer、Consumer状态展示，消息查询等常用功能，这个功能在安装好RocketMQ后需要额外单独安装、运行。