主流消息中间件ActiveMQ、RabbitMQ、RocketMQ、Kafka对比

消息中间件的主要使用场景

1.异步处理

非核心系统流程异步化，提高系统响应性能：

同步处理：用户注册过程要依次执行写数据库、发送邮件、发送短信后，才能提示用户注册成功。

异步处理：用户注册过程先写数据库，再写消息队列后就直接提示用户注册成功，发送邮件和短信通过消息队列异步处理，提高了响应速度。

2.应用解耦

系统不是强耦合，消息接受者可以随意增加，而不需要修改消息发送者的代码。消息发送者的成功不依赖消息接受者。如订单分发：

订单管理系统和各业务系统的对接通过消息队列进行解耦，各业务系统出现问题，不影响订单管理系统。当有新的业务对接进来，只需要从消息队列中拿对应的消息，订单管理系统不需要再重新对接。

3.流量削峰

当上下游系统处理能力存在差距的时候，可以用消息队列进行缓冲：

当有秒杀业务时，一下有大量请求涌入时，很可能造成系统瘫痪，此时可以用消息队列缓冲一下。

4.日志处理

将消息队列用在日志处理中，比如Kafka可以用来解决大量日志传输的问题。

5.消息通讯

消息队列一般都内置了高效的通信机制，因此也可以用于单纯的消息通讯，比如实现点对点消息队列或者聊天室等。

 

总结

ActiveMQ

• 较早推出的消息中间件，功能强大，社区也非常成熟，有较多的文档。已经在很多公司和项目中得到应用，各种协议支持较好，有多个语言的成熟客户端。主要用于中小型项目的解耦和异步处理。

• 社区活跃度越来越低，版本迭代越来越慢，性能较差，会有较低概率丢失消息，缺乏大规模吞吐的场景的应用，不推荐在新项目中继续使用。

RabbitMQ

• 基于erlang开发，所以并发能力很强，性能极好，延时很低。社区比较活跃，版本迭代较快，有比较稳定的支持。开源提供的管理界面较丰富，用起来很方便，有多个语言的成熟客户端。中小型公司首选（对消息有顺序要求的场景除外）。

• 由于是erlang开发，很难读源码，国内很少有公司有实力做erlang源码级别的研究和定制，基本只能依赖开源社区技术支持，不支持集群动态扩展。

RocketMQ

• 接口简单易用，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便。可以支撑大规模的topic数量，支持复杂MQ业务场景，经过多次阿里双11大考，可靠性和可用性值得信任。源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控。适合大型互联网应用。

• 社区活跃度一般，文档相对简单，接口这块不是按照标准JMS规范编写，有些系统要迁移需要修改大量代码，支持的语言较少。如果阿里放弃维护RocketMQ，中小型公司不一定有技术实力定制开发。

Kafka

• kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展；同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量。社区活动度比较高。用于大数据领域的实时计算、日志采集等场景，是业内标准。

• kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略。