Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别？如何保证高可用的？

Kafka 、 ActiveMQ 、 RabbitMQ 、 RocketMQ 都有什么区 别？

对于吞吐量来说 kafka 和 RocketMQ 支撑高吞吐， ActiveMQ 和 RabbitMQ 比他们低一个数量级。对于

延迟量来说 RabbitMQ 是最低的。

1. 从社区活跃度 按照目前网络上的资料， RabbitMQ 、 activeM 、 ZeroMQ 三者中，综合来看， RabbitMQ 是首

选。

2. 持久化消息比较

ActiveMq 和 RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消

息不会丢失的机制。

3. 综合技术实现

可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件

系统等等。

RabbitMq / Kafka 最好， ActiveMq 次之， ZeroMq 最差。当然 ZeroMq 也可以做到，不过自己必

须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用

性。

4. 高并发

毋庸置疑， RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的 erlang 语言。

5. 比较关注的比较， RabbitMQ 和 Kafka

RabbitMq 比 Kafka 成熟，在可用性上，稳定性上，可靠性上， RabbitMq 胜于 Kafka （理论

上）。

另外， Kafka 的定位主要在日志等方面， 因为 Kafka 设计的初衷就是处理日志的，可以看做是一个

日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。

还有就是， Kafka 的性能（吞吐量、 TPS ）比 RabbitMq 要高出来很多。

如何保证高可用的？

RabbitMQ 是比较有代表性的，因为是 基于主从 （非分布式）做高可用性的，我们就以 RabbitMQ

为例子讲解第一种 MQ 的高可用性怎么实现。 RabbitMQ 有三种模式：单机模式、普通集群模式、

镜像集群模式。

单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的 ? ，没人生产用单机模式

普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你 创建的

queue ，只会放在一个 RabbitMQ 实例上 ，但是每个实例都同步 queue 的元数据（元数据可以认

为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上

如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。 这方案主要是提

高吞吐量的 ，就是说让集群中多个节点来服务某个 queue 的读写操作。 镜像集群模式：这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在

镜像集群模式下，你创建的 queue ，无论元数据还是 queue 里的消息都会 存在于多个实例上 ，就

是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然

后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。 RabbitMQ 有很

好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以

要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这

个策略，就会自动将数据同步到其他的节点上去了。这样的话，好处在于，你任何一个机器宕机

了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它

节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导

致网络带宽压力和消耗很重！ RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，

也是每个节点都放这个 queue 的完整数据。

Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个

topic ，这个 topic 可以划分为多个 partition ，每个 partition 可以存在于不同的 broker 上，每个

partition 就放一部分数据。这就是天然的分布式消息队列，就是说一个 topic 的数据，是 分散放在

多个机器上的，每个机器就放一部分数据 。 Kafka 0.8 以后，提供了 HA 机制，就是 replica （复制

品） 副本机制。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。所有

replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是

follower 。写的时候， leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader

上的数据即可。只能读写 leader ？很简单，要是你可以随意读写每个 follower ，那么就要 care 数

据一致性的问题，系统复杂度太高，很容易出问题。 Kafka 会均匀地将一个 partition 的所有

replica 分布在不同的机器上，这样才可以提高容错性。因为如果某个 broker 宕机了，没事儿，那

个 broker 上面的 partition 在其他机器上都有副本的，如果这上面有某个 partition 的 leader ，那

么此时会从 follower 中重新选举一个新的 leader 出来，大家继续读写那个新的 leader 即可。这就

有所谓的高可用性了。写数据的时候，生产者就写 leader ，然后 leader 将数据落地写本地磁盘，

接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送

ack 给 leader ， leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当

然，这只是其中一种模式，还可以适当调整这个行为）消费的时候，只会从 leader 去读，但是只有

当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。