rocketmq、rabbitmq、kafka、activemq对比
随着互联网“微架构”模式兴起，原有大型集中式的IT服务被分拆成细粒度的多个“微服务”，这些微服务可以在一个局域网内，也可能跨机房部署。一方面对服务之间松耦合的要求越来越高，另一方面，服务之间的联系却越来越紧密，对通信质量的要求也越来越高。分布式消息队列可以提供应用解耦、流量消峰、消息分发等功能，已经成为大型互联网服务架构里标配的中间件。
1. 知名的消息引擎
- ZeroMQ
- 推特的Distributedlog
- ActiveMQ：Apache旗下的老牌消息引擎
- RabbitMQ、Kafka：AMQP的默认实现。
- RocketMQ ：阿里开源
- Artemis：Apache的ActiveMQ下的子项目
- Apollo：同样为Apache的ActiveMQ的子项目的号称下一代消息引擎
- IronMQ: 商业化的消息引擎
- 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后需要额外单独安装、运行。
