1.架构
|
主项 |
子项 |
rabbitMQ |
rocketMQ |
Kafka |
Hippo |
Tube |
|---|---|---|---|---|---|---|
|
高可用 |
|
1：镜像队列。 2：集群。master/slave机制。 |
HA 同步双写和异步复制均支持 |
（同mafka） |
|
1、中心节点：HA
|
|
高吞吐 |
|
性能 跟cpu 密切相关，5000是4核，5000左右。具体见rabbitmq基准性能测试 |
异步刷盘 单机7万qps， 三台机器12万（网测） |
（同mafka） |
未提及 |
单个Tube集群可稳定承载5w以上的客户端（生产者/消费者）数量，单台broker并发写入量可达10w TPS，使用1k大小的消息测试（机器配置：12核2.1GHz CPU带超线程、64G内存，Raid 5级磁盘阵列）时，可跑满千兆网卡带宽；Tube在绝大多数场景下可以将消息的延迟限制在毫秒级。 |
|
多机房部署 |
|
公司内无，shovel等插件支持 |
待确认 |
无 |
支持多 DC 部署 |
无 |
|
多机房容灾 |
|
公司内无，shovel等插件支持无 |
无 |
mirror maker |
未提及 |
无 |
|
高可靠 |
|
事务性， 1：producer->broker，producer 回ack的时候会在刷到盘或者消费者消费到回ack。并且会持久化 2：broker->consumer, 有确认机制。也会持久化，但是消费完会删除数据。 |
异步复制可保证99%的消息不丢失，通过同步双写技术可以完全避免单点，同步双写会对性能有一定的影响， 适合对消息要求极高的场合。 |
（同mafka） |
1. 存储可靠性 a) WAL+持久化； b)数据存储多副本 c) 存储节点自动failover；（failover 的时候会不会存在数据落后的被选为 master，具体策略没提及）
2. 传输可靠性
b) CRC 校验 （细节未提及） |
1、无事务性 2、使用了磁盘的Raid 10来保证数据的容错 3、两种情况丢消息：c pull后挂掉，机器挂掉 |
|
数据备份防止数据单点 |
|
master-slave 双写 |
服务器粒度master-slave |
Topic粒度，replica factor指定数据备份数目 |
|
|
2.特性
|
主项 |
rabbitMQ |
Kafka |
rocketMQ |
Hippo |
Tube |
|---|---|---|---|---|---|
|
1对多 |
Y |
Y |
Y |
Y |
Y |
|
消息timer （延迟消费） |
Y（队列粒度） |
N |
Y(时间梯度)、商业版本毫秒级 |
- |
|
|
event trigger？ |
N |
N |
N |
- |
|
|
group message |
Y |
Y |
Y |
Y |
Y |
|
消息tag(filter) |
N |
N |
Y |
- |
|
|
消息回溯 |
N |
Y（offset） |
Y(时间粒度、offset待确认) |
Y |
|
|
事务性 |
Y |
N |
Y |
- |
N |
|
优先级 |
Y(具体的话，数字越大优先级越大，通过插件实现的） |
N |
Y（高中低） |
- |
|
|
染色 |
N |
N |
N |
- |
|
|
文件传输(很奇怪的需求) |
N |
N |
N |
- |
|
|
持久化 |
数据库（文件） |
文件 |
文件 |
文件 |
文件 |
|
扩容 |
Y |
Y （平滑迁移，高级） |
Y |
Y |
无需扩容 |
|
多副本容灾(同机房、多机房) |
N |
mirror-maker canal-kafka |
HALF (不支持机房容灾) 针对有状态节点的难题，我们提供了一套数据自动扩容和迁移的工具来满足用户的自动扩容缩容中所产生的数据迁移类的需求。 |
未提及 |
HALF (不支持机房容灾) 跨机房部署需要解决的两大问题就是容灾和延时。当前Tube还不具备跨机房容灾的能力，但是对于Producer/Consumer端的跨机房，目前已经有在生产环境部署使用并且运行稳定，但是因为网络时延的存在，在性能和吞吐上有一定的下降 |
|
负载均衡 |
客户端咱自己封装的。 |
Y,自动 |
生产端从NameServer获取指定Topic的路由信息， 采用RR算法，从返回的队列中挑选一个队列来进行发送。 （支持失败重试和发送消息超时设置）
消费端从NameServer获取Topic下的路由信息和所有消费端， 根据平均分配算法、配置、或者机房来选择具体的队列进行消费， 做到消费端的负载均衡。 |
Producer: 从 controller 获取所有的 broker 列表，round-robin。 保持与 controller 心跳， 在 broker 发生变化时，获得更新。
Consumer: 从 controller 获取所有的 consumer 列表， 按照固定算法分配，每个 consumer 独占一个 partition。consumer 独占 partition 设置了超时。 保持与 controller 的心跳， 在 consumer 组发生变化时，获得更新并调整。
|
中心节点 |
|
消费模型 |
推拉 |
拉 |
拉 |
拉 |
拉 |
|
doubt message(消息追踪) |
Y(firehost tracer) |
N |
Y, 可以查询指定消息状态 |
- |
|
|
消息积累/消息积压 |
积压敏感，积压过多会触发集群流控，导致该集群生产消费受限制。 |
无上限 |
RocketMQ单机可以支持亿级的消息堆积能力 |
Y |
Y |
|
消息回溯 |
N |
offset回溯 |
Y，时间回溯，毫秒级 |
Y |
|
|
broker消息过滤 |
N |
|
|
|
|
|
消息轨迹 |
Y，通过插件（firehose)查询 |
N |
商业版ons支持 |
|
|
|
单机支持的TOPIC数（待确认） |
|
|
RocketMQ单机支持最高5万个队列，Load不会发生明显变化 |
|
|
3.运维成本（部署、监控等）
|
主项 |
子项 |
rabbitMQ |
Kafka |
rocketMQ |
|---|---|---|---|---|
|
工具栈 |
|
工具完善，运维方面 |
kafka manager(by yahoo) |
脚本工具 |
|
|
|
|
|
|
|
扩展项目 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
相关调研资料：
- 阿里云 ONS(Open Notification Service): 【视频】阿里分布式消息系统(ons)原理与实践 阿里分布式消息系统ONS原理与实践.pdf
来源：https://www.cnblogs.com/DarrenChan/p/9224876.html