常用消息中间件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是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

（编辑：西安站长网）

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