三个常听到的消息/中间件MQTT RabbitMQ Kafka

Q1

Q:你能给我介绍一下MQTT RabbitMQ Kafka

A:行,咱们把这三个常听到的消息/中间件名词拆开说一遍,然后放在一块儿比较一下,就知道各自适合干啥了。

1. MQTT

定位 :轻量级的发布/订阅协议
典型场景:物联网、设备上报、弱网、要省流量、省电的场景

  • 特点

    • 协议本身非常轻:头很小、格式简单,所以适合跑在嵌入式设备、传感器上。

    • Pub/Sub模型:设备往某个"主题"发消息,订阅了这个主题的人就能收到。

    • QoS等级(0/1/2)保证送达程度。

    • 常配合 Mosquitto、EMQX、HiveMQ 这类 MQTT broker 用。

    • 多用于:智能家居、车联网、工控、移动端偶尔在线偶尔离线的情况。

一句话:MQTT是协议 + 轻broker,专为"设备说话"设计的


2. RabbitMQ

定位 :通用的消息队列中间件(基于AMQP协议)
典型场景:企业业务解耦、异步任务、订单创建后发通知、延时/重试等

  • 特点

    • 支持多种交换机类型(direct、fanout、topic、headers),路由特别灵活。

    • 消息可靠性做得比较全:确认、持久化、重试、死信队列都能搞。

    • 对业务开发友好,生态成熟,管理面板好用。

    • 吞吐量中等偏上,但不是为"超高吞吐日志流"设计的。

    • 更像是"我要精细控制这条消息怎么走、失败怎么处理"。

一句话:RabbitMQ是做业务级消息的,讲究可靠、路由灵活、好管理


3. Kafka

定位 :高吞吐的分布式流式日志系统 / 消息系统
典型场景:日志采集、埋点、链路追踪、实时大数据管道、流式计算前置

  • 特点

    • 吞吐量非常高,能顶住大量生产/消费。

    • 消息是按分区顺序写磁盘的,消费者自己维护offset,要读回去也行。

    • 天生适合做**"我一直往前流"**的场景:日志、埋点、IoT大规模汇聚、实时ETL。

    • 做"精细一次只消费一条然后删了"的传统队列语义,得靠上层自己管。

    • 和 Flink / Spark Streaming 这类流计算搭配得很好。

一句话:Kafka是为"大量、顺序、可回放的消息流"生的


放在一起怎么选?

可以记下面这个思路:

  1. 是设备么?网络差不差?要省流量?

    → 是,就先想 MQTT

  2. 是后台业务,想把下单、发短信、记账、通知这种解耦,顺便要重试、死信?

    → 用 RabbitMQ 很顺手。

  3. 是海量数据流(日志、埋点、实时数仓),要求高吞吐、可回放、要接大数据组件?

    → 用 Kafka

再粗暴点说:

  • 轻 → MQTT

  • 业务 → RabbitMQ

  • 大数据流 → Kafka

Q2

Q:MQTT RabbitMQ Kafka都是订阅的吗,订阅又是什么

A:好问题,其实"订阅"这词一出来就容易让人以为它们都是同一种玩法,但细抠一下就清楚了。

我先说"订阅"到底是啥,再说这三个里谁是"天生订阅的",谁是"也能订阅但不止订阅"。

订阅是啥?

可以想成三句话:

  1. 有人发布(publish)一条消息到某个"主题/频道/Topic"上;

  2. 有人事先说:我对这个主题感兴趣(subscribe);

  3. 于是以后这个主题上来的消息就会推给这些订阅的人。

所以"订阅"="我提前说我要什么",不是临时来问"现在有消息吗"。

这就叫 发布/订阅(Pub/Sub)模型

好处:

  • 发布方不用知道谁会收

  • 订阅方也不用知道是谁发的

  • 多个订阅者可以同时收到同一条消息(广播效果)


那三个怎么回事?

1. MQTT

  • 是的,基本就是订阅的。

  • MQTT的核心就是发布/订阅 ,客户端订阅一个topic,比如 home/livingroom/temp,谁往这个topic发消息,订阅的人都能收到。

  • 所以MQTT你可以直接当"就是pub/sub"来理解。

2. RabbitMQ

  • 不是只有订阅。

  • RabbitMQ本质上是"消息队列 + 路由系统"。

  • 它能玩 点对点:一个消息进队列 → 一个消费者拿走。

  • 也能玩 发布/订阅 :用 fanouttopic 交换机把一条消息推给多个队列,每个队列后面是一个订阅者,这样就像订阅了。

  • 所以说RabbitMQ是:既能订阅式,也能队列式,看你怎么配置交换机和队列。

3. Kafka

  • 从使用体验上,也是一种订阅。

  • 你往一个 topic 里写消息

  • 不同的"消费者组"订阅这个topic

  • 它们就能读到自己该读的那部分

  • 不同组之间互不影响

  • 只不过Kafka是"我来拉(pull)"而不是"服务器推给我",但逻辑上还是:我声明我要这个topic → 我就能拿到这个topic的消息,所以也叫pub/sub。


那"订阅"和"排队"有啥区别?

  • 订阅(pub/sub) :一条消息可以被多个订阅者都看到。像群发。

  • 排队(queue / point-to-point) :一条消息只给一个消费者处理,像排号办业务。

MQTT:几乎都是订阅

RabbitMQ:两种都能做

Kafka:主要是按topic订阅来玩

相关推荐
Vizio<几秒前
STM32HAL库开发笔记-STM32CubeMX点灯
笔记·stm32·嵌入式硬件
Ahtacca几秒前
Maven 入门:项目管理与依赖管理的核心玩法
java·maven
找方案6 分钟前
hello-agents 学习笔记:智能体发展史 —— 从符号逻辑到 AI 协作的进化之旅
人工智能·笔记·学习·智能体·hello-agents
a程序小傲6 分钟前
京东Java面试被问:Fork/Join框架的使用场景
java·开发语言·后端·postgresql·面试·职场和发展
⑩-10 分钟前
Java四种线程创建方式
java·开发语言
月光在发光11 分钟前
22_GDB调试记录(未完成)
java·开发语言
222you13 分钟前
SpringAOP的介绍和入门
java·开发语言·spring
蒙奇D索大19 分钟前
【数据结构】考研408 | 平方探测法精讲:跳跃探查的艺术与聚集迷思
数据结构·笔记·考研·改行学it
Violet_YSWY22 分钟前
哪些常量用枚举,哪些用类
java
shoubepatien23 分钟前
JAVA -- 09
java·开发语言