协议对比

MQTT 与 Kafka：设备消息还是持久化事件流？

MQTT 通过轻量级 Broker 连接受限客户端。Kafka 存储有序的事件流，用于高吞吐量处理和重放。许多物联网系统需要在边缘使用 MQTT，并在数据摄取边界后使用 Kafka。

了解 MQTT 基础知识探索托管式 MQTT

比较操作模型，而不仅仅是吞吐量

这些协议解决了不同的边界。MQTT 优化设备连接；Kafka 优化持久化处理骨干网。

MQTT

一种为间歇性网络、受限设备、分层主题和 Broker 推送消息而构建的紧凑型发布/订阅协议。

最适用于设备到云和命令控制消息。

Apache Kafka

一个为持久化保留、分区吞吐量、消费者控制的偏移量、重放和流处理而构建的分布式事件日志。

最适用于服务到服务的事件管道、分析和重放。

能力
能力	MQTT	Kafka
核心模型	带分层主题的 Broker 消息发布/订阅	带消费者偏移量的分区追加日志
典型客户端	传感器、嵌入式设备、网关、移动客户端	后端服务、连接器、流处理器
消息投递	Broker 推送匹配消息；QoS 0、1 或 2	消费者拉取并按消费者组提交偏移量
保留和重放	保留的最新值和会话队列；并非通用事件存档	基于时间或大小的持久化保留和偏移量重放
路由	带有 + 和 # 通配符的分层主题过滤器	扁平主题和分区；路由属于生产者或处理器
网络假设	专为低带宽、高延迟和重连客户端设计	专为稳定的数据中心或云服务连接设计

根据数据传输的边界选择

单个系统可以在不重复职责的情况下同时使用两者。

选择 MQTT

当受限或间歇连接的客户端需要低开销的遥测、命令、会话行为和主题级扇出时。

选择 Kafka

当后端团队需要持久化的事件历史、多个独立消费者、重放、分区排序和流处理时。

两者都使用

由 MQTT 承接设备会话，再将选定事件流送入 Kafka，用于持久分析、数据增强和下游消费。

实用的 MQTT 到 Kafka 边界

明确协议职责，使重放、背压和授权保持清晰可理解。

在摄取时标准化

在持久化存储前，验证有效载荷，附加设备和租户上下文，并拒绝格式错误的事件。

选择分区键

保留业务所需的排序单元，例如设备、资产、站点或账户。

分离命令路径

不要将每个后端事件都转换为设备命令。在发布回 MQTT 之前，应用策略、过期、幂等性和审批。

MQTT 与 Kafka 常见问题解答

Kafka 能否替代 MQTT Broker？

Kafka 不是即插即用的设备 Broker。它不提供 MQTT 会话、QoS 流、保留消息、分层主题过滤器或相同的受限客户端足迹。

MQTT 能否替代 Kafka 用于事件历史记录？

MQTT 可以队列会话消息并保留最新值，但它并非为许多独立后端消费者设计的长期可重放事件日志。

MQTT 到 Kafka 的桥接器应在哪里运行？

应部署在受控的数据接入边界，确保凭据、Schema、重试、分区键和死信处理都可运维、可观测。