消息队列MQ选型 - Kafka、RabbitMQ对比

消息队列MQ选型 - Kafka、RabbitMQ对比
image.png

适应场景

异步处理,应用解耦,流量削锋和消息通讯

对比

feature scenario Kafka RabbitMQ 备注
PUB-SUB 发布订阅模型
推拉消费 Consumer消费消息的动作方式。 pull push/pull push更关注实时性。pull更关注消费者消费能力。
延迟消费 Producer产生一条消息后,并不希望立刻被消费掉。 X 高阶需求。
consumer group 同一条Message能同时被多个消费组消费,但同一group中,一条Message只会被一个consumer消费 KAFKA: 不需要在管理平台配置。 RabbitMQ:增加需要配置,涉及到内部数据冗余。
消息tag(filter) 以过滤出tag为keyword的message X X
消息回溯 从历史中的某个位置重新拉取消息 X X 只对拉模式,推模式不考虑回溯,支持时间维度offset
事务性 mq内部逻辑,消息状态是否一致 X 和消息中间件内部实现相关。
优先级 消息优先级,consumer优先消费高优先级消息。 X
染色 追踪消息在mq中的具体耗时 X X
本地读优化 Producer\Consumer 不在同一机房。MQ搭建在P端,C端会存在跨机房访问的问题。 X X 使用数据同步工具,将P所在机房数据同步到C所在机房的集群。
doubt message(消息追踪) 跨公司,异构系统间,消息状态追踪。 X X
消息积压 没有被消费的消息在MQ中堆积 支持程度的区别,不同mq会存在不同。
负载均衡 1:防止单点 2:C端压力LB在MQ各节点上。 RMQ:多集群做负载
支持的消息大小 每条消息的大小 无限制 无限制 需要对消息大小做限制,降低系统不确定性。
定期回收消息 mq中的消息一旦被消费后,可以被删除,空间回收。
消费语义 方式分别为:1、最多消费一次 2、最少消费一次3、仅消费一次 2 2 业务方消费端做幂等
对全局序支持 消息在全局保持时序一致 X X 设计复杂度原因,不考虑支持

备注:
“√” 表示目前系统已主持
“X” 表示系统不考虑支持该特性


欢迎关注 高广超的简书博客 与 收藏文章 !
欢迎关注 头条号:互联网技术栈

个人介绍:

高广超 :多年一线互联网研发与架构设计经验,擅长设计与落地高可用、高性能互联网架构。

本文首发在 高广超的简书博客 转载请注明!

消息队列MQ选型 - Kafka、RabbitMQ对比
image.png
上一篇:设计模式- 合成/组合原则


下一篇:消息队列探秘-RabbitMQ消息队列介绍