Kafka、RabbitMQ、RocketMQ 消息中间件的对比

什么是消息队列？

消息队列是在消息的传输过程中保存消息的容器，包含以下 3 元素：

• Producer：消息生产者，负责产生和发送消息到 Broker；

• Broker：消息处理中心，负责消息存储、确认、重试等，一般其中会包含多个 Queue；

• Consumer：消息消费者，负责

• 从 Broker 中获取消息，并进行相应处理。

消息队列模式

• 点对点模式：多个生产者可以向同一个消息队列发送消息，一个具体的消息只能由一个消费者消费。

• 发布/订阅模式：单个消息可以被多个订阅者并发的获取和处理。

 

消息队列应用场景

• 应用解耦：消息队列减少了服务之间的耦合性，不同的服务可以通过消息队列进行通信，而不用关心彼此的实现细节。

• 异步处理：消息队列本身是异步的，它允许接收者在消息发送很长时间后再取回消息。

• 流量削锋：当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的”载体”，在下游有能力处理的时候，再进行分发与处理。

• 日志处理：日志处理是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。

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

• 消息广播：如果没有消息队列，每当一个新的业务方接入，我们都要接入一次新接口。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。

常用消息队列

官方社区现在对 ActiveMQ 维护越来越少，较少在大规模吞吐的场景中使用，主要使用 Kafka、RabbitMQ 和 RocketMQ。

消息队列对比 

Kafka

优点：

• 高吞吐：Kafka 最大的特点就是收发消息非常快，Kafka 每秒可以处理几十万条消息，它的最低延迟只有几毫秒。

缺点：

• Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长；

• 不支持消息路由，不支持延迟发送，不支持消息重试；

• 社区更新较慢。

RocketMQ

优点：

• 高吞吐：借鉴 Kafka 的设计，单一队列百万消息的堆积能力；

• 高伸缩性：灵活的分布式横向扩展部署架构，整体架构其实和 kafka 很像；

• 高容错性：通过ACK机制，保证消息一定能正常消费；

• 持久化、可回溯：消息可以持久化到磁盘中，支持消息回溯；

缺点：

• 不支持消息路由，支持的客户端语言不多，目前是 java 及 c++，其中 c++ 不成熟；

• 社区活跃度一般。

RabbitMQ

优点：

• 支持几乎所有最受欢迎的编程语言：Java，C，C ++，C＃，Ruby，Perl，Python，PHP等等；

• 支持消息路由：RabbitMQ 可以通过不同的交换器支持不同种类的消息路由；

• 消息时序：通过延时队列，可以指定消息的延时时间，过期时间TTL等；

• 支持容错处理：通过交付重试和死信交换器（DLX）来处理消息处理故障；

• 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker；

• 社区活跃度高。

缺点：

• Erlang 开发，很难去看懂源码，不利于做二次开发和维护，基本只能依赖于开源社区的快速维护和修复 bug；

• RabbitMQ 吞吐量会低一些，这是因为他做的实现机制比较重；

• 不支持消息有序、持久化不好、不支持消息回溯、伸缩性一般。

消息队列选型

选择rabbitMQ情况，高级灵活的路由规则，需要延迟队列的支持。

RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。

语言
kafka使用scala写的，rabbitmq使用erlang写的，rocketMQ使用java写的