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

相关推荐
gladiator+6 分钟前
Redis之BigKey的常见问题以及大厂相关面试题
java·数据库·redis
AA陈超8 分钟前
Git常用命令大全及使用指南
笔记·git·学习
Controller-Inversion36 分钟前
岛屿问题(dfs典型问题求解)
java·算法·深度优先
okseekw1 小时前
Java 字符串三巨头:String、StringBuilder、StringJoiner —— 初学者避坑指南 🤯
java
愚戏师1 小时前
Python3 Socket 网络编程复习笔记
网络·笔记
毕设源码余学姐1 小时前
计算机毕设 java 中医药药材分类采购网站 SSM 框架药材交易平台 Java 开发的分类采购与订单管理系统
java·开发语言·课程设计
BD_Marathon1 小时前
【JUC】并发与并行
java
okseekw1 小时前
Java String类详解:不可变性、创建方式与比较方法
java
q***64971 小时前
Spring Boot 各种事务操作实战(自动回滚、手动回滚、部分回滚)
java·数据库·spring boot
降临-max2 小时前
JavaSE---网络编程
java·开发语言·网络·笔记·学习