MQTT
一种为间歇性网络、受限设备、分层主题和 Broker 推送消息而构建的紧凑型发布/订阅协议。
最适用于设备到云和命令控制消息。
协议对比
MQTT 与 Kafka：设备消息还是持久化事件流？
如果只需要实时设备连接与指令，而不需要可重放的后端日志，请单独使用 MQTT；如果生产者均为可信后端服务，且需要持久事件处理，请单独使用 Kafka；如果受限设备需要边缘 MQTT 会话，而多个后端消费者需要保留和重放事件，请在受控 Bridge 两侧组合使用两者。
比较操作模型，而不仅仅是吞吐量
这些协议解决了不同的边界。MQTT 优化设备连接；Kafka 优化持久化处理骨干网。
Apache Kafka
一个为持久化保留、分区吞吐量、消费者控制的偏移量、重放和流处理而构建的分布式事件日志。
最适用于服务到服务的事件管道、分析和重放。
| 能力 | MQTT | Kafka |
|---|---|---|
| 设备连接生命周期 | 原生适配轻量客户端、Keepalive、会话、重连与 Last Will | 后端客户端需要稳定连接并支持 Kafka 协议 |
| 核心模型 | 带分层主题的 Broker 消息发布/订阅 | 带消费者偏移量的分区追加日志 |
| 典型客户端 | 传感器、嵌入式设备、网关、移动客户端 | 后端服务、连接器、流处理器 |
| 消息投递 | Broker 推送匹配消息；QoS 0、1 或 2 | 消费者拉取并按消费者组提交偏移量 |
| 指令下行 | 通过 Broker 推送指令 Topic，并实施单设备授权、过期时间与确认 | 需要应用网关进行授权，并将事件转换成设备指令 |
| 保留和重放 | 保留的最新值和会话队列；并非通用事件存档 | 基于时间或大小的持久化保留和偏移量重放 |
| 顺序与分区 | 顺序限定于客户端连接和 Topic 投递，不提供消费者 Partition 模型 | Record Key 决定 Partition；只保证单个 Partition 内有序 |
| 独立处理消费者 | 订阅负责实时扇出；共享订阅可分配工作，但没有持久 Offset | Consumer Group 维护独立 Offset，并跨 Partition 扩展处理能力 |
| 路由 | 带有 + 和 # 通配符的分层主题过滤器 | 扁平主题和分区；路由属于生产者或处理器 |
| 网络假设 | 专为低带宽、高延迟和重连客户端设计 | 专为稳定的数据中心或云服务连接设计 |
根据数据传输的边界选择
单个系统可以在不重复职责的情况下同时使用两者。
选择 MQTT
当受限或间歇连接的客户端需要低开销的遥测、命令、会话行为和主题级扇出时。
选择 Kafka
当后端团队需要持久化的事件历史、多个独立消费者、重放、分区排序和流处理时。
两者都使用
由 MQTT 承接设备会话，再将选定事件流送入 Kafka，用于持久分析、数据增强和下游消费。
实用的 MQTT 到 Kafka 边界
明确协议职责，使重放、背压和授权保持清晰可理解。
1. 在进入 Bridge 前完成认证
MQTT Broker 负责认证每台设备并强制执行其发布 Topic。Bridge 信任 Broker 已授权的路由，而不是载荷中由设备提供的 deviceId。
2. 有意识地映射 Topic
只订阅获准的遥测 Filter。按事件领域映射到少量 Kafka Topic，不要把每个 MQTT Topic 原样复制到 Kafka。
3. 校验并封装事件
校验版本化载荷，从已授权 Topic 推导租户和设备上下文，并在写入前添加接入时间与稳定 Event ID。
4. 选择有序性边界
使用需要有序性的最小业务单元作为 Record Key，通常是 deviceId 或 assetId。Kafka 不提供跨 Partition 的全局顺序。
5. 限制重试并处理死信
对瞬时写入失败进行退避重试。将无效或超过重试次数的记录连同原因送入受限 DLQ，并触发告警；不要静默循环。
6. 观测边界两侧
关联 MQTT Client 与 Topic、Kafka Topic、Partition、Offset、Event ID、重试次数、DLQ 比例、队列年龄和端到端延迟，同时不记录密钥。
7. 将指令放在受控返回路径中
由独立服务授权 Kafka 派生动作，添加 Operation ID 和过期时间，使用指令专用 MQTT 身份发布，并核对设备确认。
参考数据流与责任交接
- 01
设备群
唯一身份；版本化遥测
- 02
MQTT Broker
TLS、会话、Topic ACL、指令投递
- 03
接入 Bridge
Schema、Envelope、重试、DLQ
- 04
Kafka Topic
分区保留与重放
- 05
Consumer Group
独立处理与 Offset
可运行的本地 Bridge，并明确其限制
仓库示例会启动仅绑定到本机回环地址的 Mosquitto 和 Redpanda 容器，校验合成遥测 Schema，以 deviceId 作为 Kafka Record Key，对失败进行有界重试，并将无效记录路由到 DLQ。它只是学习用夹具，并非生产 Connector：本地匿名 Broker 不提供设备身份，Bridge 在 MQTT 确认与 Kafka 确认之间也没有持久 Spool。
在仓库根目录运行
docker compose -f public/examples/mqtt-kafka-bridge/compose.yaml up -d
pnpm mqtt:kafka-bridge
# In a second shell, publish a synthetic event
docker compose -f public/examples/mqtt-kafka-bridge/compose.yaml exec mosquitto \
mosquitto_pub -h 127.0.0.1 -t lab/device-042/telemetry -q 1 \
-m '{"eventId":"evt-001","recordedAt":"2026-01-01T00:00:00Z","value":21.4}'协议与实现资料
MQTT 与 Kafka 常见问题解答
Kafka 能否替代 MQTT Broker？
Kafka 不是即插即用的设备 Broker。它不提供 MQTT 会话、QoS 流、保留消息、分层主题过滤器或相同的受限客户端足迹。
MQTT 能否替代 Kafka 用于事件历史记录？
MQTT 可以队列会话消息并保留最新值，但它并非为许多独立后端消费者设计的长期可重放事件日志。
MQTT 到 Kafka 的桥接器应在哪里运行？
应部署在受控的数据接入边界，确保凭据、Schema、重试、分区键和死信处理都可运维、可观测。