@kafkalistener消费不到消息_案例精选 | 分布式消息队列差异化总结，太全了！

导读：本文将对Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ从17 个方面综合对比作为消息队列使用时的差异。

资料文档

• Kafka：资料数量中等。有Kafka作者自己写的书，网上资料也有一些。

• RabbitMQ：资料数量多。有一些不错的书，网上资料多。

• ZeroMQ：资料数量少。专门写ZeroMQ的书较少，网上的资料多是一些代码的实现和简单介绍。

• RocketMQ：资料数量少。专门写RocketMQ的书目前有了两本；网上的资料良莠不齐，官方文档很简洁，但是对技术细节没有过多的描述。

• ActiveMQ：资料数量多。没有专门写ActiveMQ的书，网上资料多。

开发语言

• Kafka：Scala

• RabbitMQ：Erlang

• ZeroMQ：C

• RocketMQ：Java

• ActiveMQ：Java

支持的协议

• Kafka：自己定义的一套…(基于TCP) 

• RabbitMQ：AMQP 

• ZeroMQ：TCP、UDP 

• RocketMQ：自己定义的一套… 

• ActiveMQ：OpenWire、STOMP、REST、XMPP、AMQP

消息存储

Kafka

内存、磁盘、数据库。支持大量堆积。Kafka的最小存储单元是分区，一个topic包含多个分区，Kafka创建主题时，这些分区会被分配在多个服务器上，通常一个broker一台服务器。

分区首领会均匀地分布在不同的服务器上，分区副本也会均匀的分布在不同的服务器上，确保负载均衡和高可用性，当新的broker加入集群的时候，部分副本会被移动到新的broker上。

根据配置文件中的目录清单，Kafka会把新的分区分配给目录清单里分区数最少的目录。

默认情况下，分区器使用轮询算法把消息均衡地分布在同一个主题的不同分区中，对于发送时指定了key的情况，会根据key的hashcode取模后的值存到对应的分区中。

RabbitMQ

内存、磁盘。支持少量堆积。RabbitMQ的消息分为持久化的消息和非持久化消息，不管是持久化的消息还是非持久化的消息都可以写入到磁盘。

持久化的消息在到达队列时就写入到磁盘，并且如果可以，持久化的消息也会在内存中保存一份备份，这样可以提高一定的性能，当内存吃紧的时候会从内存中清除。

非持久化的消息一般只存在于内存中，在内存吃紧的时候会被换入到磁盘中，以节省内存。

引入镜像队列机制，可将重要队列“复制”到集群中的其他broker上，保证这些队列的消息不会丢失。配置镜像的队列，都包含一个主节点master和多个从节点slave,如果master失效，加入时间最长的slave会被提升为新的master，除发送消息外的所有动作都向master发送，然后由master将命令执行结果广播给各个slave，RabbitMQ会让master均匀地分布在不同的服务器上，而同一个队列的slave也会均匀地分布在不同的服务器上，保证负载均衡和高可用性。

ZeroMQ

消息发送端的内存或者磁盘中。不支持持久化。

RocketMQ

磁盘。支持大量堆积。commitLog文件存放实际的消息数据，每个commitLog上限是1G，满了之后会自动新建一个commitLog文件保存数据。

ConsumeQueue队列只存放offset、size、tagcode，非常小，分布在多个broker上。ConsumeQueue相当于CommitLog的索引文件，消费者消费时会从consumeQueue中查找消息在commitLog中的offset，再去commitLog中查找元数据。

ConsumeQueue存储格式的特性，保证了写过程的顺序写盘(写CommitLog文件)，大量数据IO都在顺序写同一个commitLog，满1G了再写新的。加上RocketMQ是累计4K才强制从PageCache中刷到磁盘(缓存)，所以高并发写性能突出。

ActiveMQ

内存、磁盘、数据库。支持少量堆积。

消息事务

• Kafka：支持

• RabbitMQ：支持。

  客户端将信道设置为事务模式，只有当消息被RabbitMQ接收，事务才能提交成功，否则在捕获异常后进行回滚。使用事务会使得性能有所下降

• ZeroMQ：不支持

• RocketMQ：支持

• ActiveMQ：支持

负载均衡

Kafka