常用消息中间件17个维度全方位对比

客户端均衡算法：

• 轮询法。按顺序返回下一个服务器的连接地址。
• 加权轮询法。给配置高、负载低的机器配置更高的权重，让其处理更多的请求;而配置低、负载高的机器，给其分配较低的权重，降低其系统负载。
• 随机法。随机选取一个服务器的连接地址。
• 加权随机法。按照概率随机选取连接地址。
• 源地址哈希法。通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算。
• 最小连接数法。动态选择当前连接数最少的一台服务器的连接地址。

zeromq：去中心化，不支持负载均衡。本身只是一个多线程网络库。

rocketmq：支持负载均衡。

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

nameserver与每个集群成员保持心跳，保存着Topic-Broker路由信息，同一个topic的队列会分布在不同的服务器上。

发送消息通过轮询队列的方式发送，每个队列接收平均的消息量。发送消息指定topic、tags、keys，无法指定投递到哪个队列(没有意义，集群消费和广播消费跟消息存放在哪个队列没有关系)。

tags选填，类似于 Gmail 为每封邮件设置的标签，方便服务器过滤使用。目前只支 持每个消息设置一个 tag，所以也可以类比为 Notify 的 MessageType 概念。

keys选填，代表这条消息的业务关键词，服务器会根据 keys 创建哈希索引，设置后， 可以在 Console 系统根据 Topic、Keys 来查询消息，由于是哈希索引，请尽可能 保证 key 唯一，例如订单号，商品 Id 等。

rocketmq的负载均衡策略规定：Consumer数量应该小于等于Queue数量，如果Consumer超过Queue数量，那么多余的Consumer 将不能消费消息。这一点和kafka是一致的，rocketmq会尽可能地为每一个Consumer分配相同数量的队列，分摊负载。

activemq：支持负载均衡。可以基于zookeeper实现负载均衡。

七 集群方式

Kafka：天然的‘Leader-Slave’无状态集群，每台服务器既是Master也是Slave。

分区首领均匀地分布在不同的kafka服务器上，分区副本也均匀地分布在不同的kafka服务器上，所以每一台kafka服务器既含有分区首领，同时又含有分区副本，每一台kafka服务器是某一台kafka服务器的Slave，同时也是某一台kafka服务器的leader。

kafka的集群依赖于zookeeper，zookeeper支持热扩展，所有的broker、消费者、分区都可以动态加入移除，而无需关闭服务，与不依靠zookeeper集群的mq相比，这是最大的优势。

rabbitmq：支持简单集群，'复制'模式，对高级集群模式支持不好。

rabbitmq的每一个节点，不管是单一节点系统或者是集群中的一部分，要么是内存节点，要么是磁盘节点，集群中至少要有一个是磁盘节点。

在rabbitmq集群中创建队列，集群只会在单个节点创建队列进程和完整的队列信息(元数据、状态、内容)，而不是在所有节点上创建。

引入镜像队列，可以避免单点故障，确保服务的可用性，但是需要人为地为某些重要的队列配置镜像。

zeromq：去中心化，不支持集群。

rocketmq：常用 多对'Master-Slave' 模式，开源版本需手动切换Slave变成Master

Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。

Producer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。

Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

客户端先找到NameServer, 然后通过NameServer再找到 Broker。

一个topic有多个队列，这些队列会均匀地分布在不同的broker服务器上。rocketmq队列的概念和kafka的分区概念是基本一致的，kafka同一个topic的分区尽可能地分布在不同的broker上，分区副本也会分布在不同的broker上。

rocketmq集群的slave会从master拉取数据备份，master分布在不同的broker上。

activemq：支持简单集群模式，比如'主-备'，对高级集群模式支持不好。

八 管理界面

• Kafka：一般
• rabbitmq：好
• zeromq：无
• rocketmq：无
• activemq：一般

九 可用性

• Kafka：非常高(分布式)
• rabbitmq：高(主从)
• zeromq：高
• rocketmq：非常高(分布式)
• activemq：高(主从)

十 消息重复

• Kafka：支持at least once、at most once
• rabbitmq：支持at least once、at most once
• zeromq：只有重传机制，但是没有持久化，消息丢了重传也没有用。既不是at least once、也不是at most once、更不是exactly only once
• rocketmq：支持at least once
• activemq：支持at least once

十一 吞吐量TPS

（编辑：三明站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!