消息队列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” 表示系统不考虑支持该特性

---

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

个人介绍：

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

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

image.png