Hi! 我是小小，我们今天又见面了，今天主要内容是从十七个方面对比kafka，rabbitmq，zeromq，rocketmq，activemq，更加方便你的技术选型哦！

资料文档

1. kafaka：在kafka中，有作者自己写的书，网上的资料也有一点
2. rabbitmq，多，有很多不错的数，网络上资料也多。
3. zeromq，少，没有专门写zeromq的书，网上的资料多是代码实现和简单介绍。
4. rocketmq，少，没有专门写rocketmq的数，网络上的良莠不齐，官方文档简单，但是对技术细节没有过多的描述。
5. activemq，多，没有专门写activemq的书，网上资料多。

开发语言

kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：Java activemq：Java

支持的协议

1. kafka 自己定义的一套，基于TCP
2. rabbitmq：AMQP
3. zeromq：TCP，UDP
4. rocketmq：自己定义的一套
5. activemq：OpenWire，STOMP，REST，XMPP，AMQP

消息存储

1. kafka：内存，磁盘，数据库，支持大量堆积 kafka 的最小存储单元是分区，一个topic包含多个分区，kafka创建分区的时候，这些分区会被分配在多个服务器上，通常一个节点是一台服务器，分区会均匀的分布在不同的服务器上，分区的副本也会均匀的分布在不同的服务器上，确保负载均衡以及高可用。当新的节点加入集群的时候，部分副本会自动迁移到新的节点上，根据配置文件中的目录，会自己吧新的分区分配非目录分区里分区数最少的目录。
2. rabbitmq: 内存，磁盘，支持少量堆积 rabbitmq的消息分为持久化消息和非持久化消息，不管是否是不是持久化消息，其都会写入到磁盘里，其中，持久化的消息也同样会在内存里保存一份，这样做的目的是提高性能。引入了镜像队列机制，可以吧重要的队列复制到集群中其他节点上，保证这些队列消息不丢失，配置镜像队列，包含一个主节点，master和从节点slave，如果master节点失效，从节点会自动变成主节点。rabbitmq会让master均匀的分布在不同的服务器上，而同一个队列的slave也会均匀的分布在不同的服务器上，保证负载均衡和高可用。
3. zeromq：消息发送端的内存或者磁盘中保存，不支持持久化。
4. rocketmq：磁盘，支持大量堆积。日志文件存放的是实际的消息数据，每个日志文件上限是1G，满看之后会自动新建一个日志文件保存数据。ConsumeQueue队列只存放offset，size，tagcode数据，非常小，分布在多个节点上。其中consumequeue相当于日志文件的索引文件，消费者消费的时候，从consumequeue中查找消息的在日志文件中查找到offset，再去commitlog中查找元数据。
5. activemq：内存，磁盘，数据库，支持少量堆积。

消息事物

1. kafka 支持
2. rabbitmq：支持，客户端吧信道设置为事物模式以后，只有当消息被rabbitmq接收以后，事物才能提交成功，否则进行回滚，
3. zeromq：不支持
4. rocketmq：支持
5. activemq：支持

负载均衡

kafka

1. 一个节点通常就是一台服务器节点。对于同一个Topic的不同分区，Kafka会尽力将这些分区分布到不同的节点服务器上，zookeeper保存了节点信息、主题和分区的元数据信息。分区首领会处理来自客户端的生产请求，kafka分区首领会被分配到不同的节点服务器上，让不同的节点服务器共同分担任务。每一个节点都缓存了元数据信息，客户端可以从任意一个节点获取元数据信息并缓存起来，根据元数据信息知道要往哪里发送请求。
2. kafka的消费者组订阅同一个topic，会尽可能地使得每一个消费者分配到相同数量的分区，分摊负载。
3. 当消费者加入或者退出消费者组的时候，还会触发再均衡，为每一个消费者重新分配分区，分摊负载。

kafka的负载均衡大部分是自动完成的，分区的创建也是kafka完成的，隐藏了很多细节，避免了繁琐的配置和人为疏忽造成的负载问题。4. 发送端由topic和key来决定消息发往哪个分区，如果key为null，那么会使用轮询算法将消息均衡地发送到同一个topic的不同分区中。如果key不为null，那么会根据key的hashcode取模计算出要发往的分区。

rabbitmq

对负债均衡支持不好

rabbitmq客户端发送消息要和broker建立连接，需要事先知道broker上有哪些交换器，有哪些队列。通常要声明要发送的目标队列，如果没有目标队列，会在broker上创建一个队列，如果有，就什么都不处理，接着往这个队列发送消息。假设大部分繁重任务的队列都创建在同一个broker上，那么这个broker的负载就会过大。(可以在上线前预先创建队列，无需声明要发送的队列，但是发送时不会尝试创建队列，可能出现找不到队列的问题，rabbitmq的备份交换器会把找不到队列的消息保存到一个专门的队列中，以便以后查询使用)

使用镜像队列机制建立rabbitmq集群可以解决这个问题，形成master-slave的架构，master节点会均匀分布在不同的服务器上，让每一台服务器分摊负载。slave节点只是负责转发，在master失效时会选择加入时间最长的slave成为master。

当新节点加入镜像队列的时候，队列中的消息不会同步到新的slave中，除非调用同步命令，但是调用命令后，队列会阻塞，不能在生产环境中调用同步命令。2. 当rabbitmq队列拥有多个消费者的时候，队列收到的消息将以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者，不会重复。

这种方式非常适合扩展，而且是专门为并发程序设计的。

如果某些消费者的任务比较繁重，那么可以设置basicQos限制信道上消费者能保持的最大未确认消息的数量，在达到上限时，rabbitmq不再向这个消费者发送任何消息。3. 对于rabbitmq而言，客户端与集群建立的TCP连接不是与集群中所有的节点建立连接，而是挑选其中一个节点建立连接。

但是rabbitmq集群可以借助HAProxy、LVS技术，或者在客户端使用算法实现负载均衡，引入负载均衡之后，各个客户端的连接可以分摊到集群的各个节点之中。

rocketmq

支持负载均衡 一个broker通常是一个服务器节点，broker分为master和slave,master和slave存储的数据一样，slave从master同步数据。

activemq

支持负载均衡，可以基于zookeeper实现负债均衡

管理界面

1. kafka：一般
2. rabbitmq：好
3. zeromq：无
4. rocketmq：无
5. activemq：一般

可用性

1. kafka：非常高
2. rabbitmq：高
3. zeromq: 高
4. rocketmq：非常高
5. activemq：高

吞吐量

1. Kafka：极大 Kafka按批次发送消息和消费消息。发送端将多个小消息合并，批量发向Broker，消费端每次取出一个批次的消息批量处理。
2. rabbitmq：比较大
3. zeromq：极大
4. rocketmq：大  rocketMQ接收端可以批量消费消息，可以配置每次消费的消息数，但是发送端不是批量发送。
5. activemq：比较大

顺序消息

kafka

Kafka：支持。

设置生产者的max.in.flight.requests.per.connection为1，可以保证消息是按照发送顺序写入服务器的，即使发生了重试。

kafka保证同一个分区里的消息是有序的，但是这种有序分两种情况

1. key为null，消息逐个被写入不同主机的分区中，但是对于每个分区依然是有序的

2. key不为null , 消息被写入到同一个分区，这个分区的消息都是有序。

rabbitmq

rabbitmq：不支持

zeromq

zeromq：不支持

rocketmq

rocketmq：支持

activemq

activemq：不支持

并发度

kafka

Kafka：高

一个线程一个消费者，kafka限制消费者的个数要小于等于分区数，如果要提高并行度，可以在消费者中再开启多线程，或者增加consumer实例数量。

rabbitmq

rabbitmq：极高

本身是用Erlang语言写的，并发性能高。

zeromq

zeromq：高

rocketmq

rocketmq：高

1. rocketmq限制消费者的个数少于等于队列数，但是可以在消费者中再开启多线程，这一点和kafka是一致的，提高并行度的方法相同。
2. 同一个网络连接connection，客户端多个线程可以同时发送请求，连接会被复用，减少性能开销。

activemq

activemq：高

单个ActiveMQ的接收和消费消息的速度在1万笔/秒(持久化 一般为1-2万， 非持久化 2 万以上)，在生产环境中部署10个Activemq就能达到10万笔/秒以上的性能，部署越多的activemq broker 在MQ上latency也就越低，系统吞吐量也就越高。

0、大写的服，看完这篇你还不懂RocketMQ算我输