三个常听到的消息/中间件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订阅来玩

相关推荐
Flittly5 小时前
【AgentScope Java新手村系列】(16)从RAG到多路检索
java·spring boot·spring
小兔崽子去哪了5 小时前
Java 生成二维码解决方案
java·后端
人活一口气10 小时前
从JVM调优到MCP协议:Java全栈技术体系深度总结与企业级架构实践
java·spring boot
NE_STOP11 小时前
Vibe Coding -- 完整项目案例实操
java
荣码11 小时前
GraphRAG:普通RAG只能回答"点"的问题,我踩了4个坑才搞懂
java·python
SimonKing11 小时前
Google第三方授权登录
java·后端·程序员
明月光81812 小时前
从一行 @Builder 说起:重新拾起 Java 的 Lombok、注解与 Builder 模式
java
考虑考虑21 小时前
Mybatis实现批量插入
java·后端·mybatis
咖啡八杯1 天前
GoF设计模式——中介者模式
java·后端·spring·设计模式
青石路1 天前
记一次多JDK版本问题的排查,一坑套一坑,差点没爬上来
java