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

相关推荐
论迹2 小时前
【Spring Cloud 微服务】-- 服务拆分原则
java·spring cloud·微服务
汤姆yu2 小时前
基于springboot的民间救援队救助系统
java·spring boot·后端·救援队
闭着眼睛学算法2 小时前
【双机位A卷】华为OD笔试之【哈希表】双机位A-采购订单【Py/Java/C++/C/JS/Go六种语言】【欧弟算法】全网注释最详细分类最全的华子OD真题题解
java·华为od·散列表
勿忘,瞬间2 小时前
Maven
java·maven
一 乐3 小时前
高校教务|教务管理|基于springboot+vue的高校教务管理系统(源码+数据库+文档)
java·数据库·vue.js·spring boot·后端·教务管理
数字冰雹3 小时前
重塑城市公共安全管理的“智慧之眼”
java·大数据·数据库
August_._3 小时前
【MySQL】触发器、日志、锁机制 深度解析
java·大数据·数据库·人工智能·后端·mysql·青少年编程
Halo_tjn3 小时前
基于 Object 类及包装类的专项实验
java·开发语言·计算机
百锦再3 小时前
第10章 错误处理
java·git·ai·rust·go·错误·pathon