通过MQTT传输单条约100MB的大量数据是否是合理选择？

结论先行：哪怕MQTT协议规范最高支持256MB的单条消息，也完全不建议用它传输单条100MB级别的数据，行业通用的1MB以内的限制是经过大量实际场景验证的最优实践。

不建议这么做的核心原因 #

• 协议定位不匹配：MQTT从设计之初就是面向低带宽、不稳定网络环境下的小数据传输场景，核心优势是报文头开销极小、功耗低、适配弱网环境，传输100MB级别的大消息完全无法发挥它的设计优势，反而会暴露它的短板。
• 传输容错成本极高：MQTT的QoS 1、QoS 2可靠性保障机制是针对完整消息生效的，单条100MB的消息如果传输到99%时出现网络波动，就需要整个消息完全重传，不仅会浪费大量带宽，还会长时间占用甚至打满设备内存，性能差的端侧设备或者配置较低的MQTT broker甚至会直接因为内存溢出崩溃。而单条消息控制在1MB以内时，就算需要重传的成本也可控，这也是行业普遍遵循这个限制的核心原因之一。
• 集群性能损耗严重：主流MQTT broker的默认配置大多会把单条消息上限设置在几KB到几MB不等，远低于协议规定的256MB上限，原因就是大消息会严重拉低整个broker的吞吐能力，单条大消息传输时会阻塞同连接下的其他小消息传输，导致所有业务的消息延迟大幅升高，高并发场景下甚至会引发整个broker集群雪崩。

可行的替代方案 #

如果确实存在100MB级别的数据传输需求，可以选择更适配的实现方案：

• 方案一：将大文件切片为1KB~1MB大小的分片，给每个分片标注唯一序号和所属文件标识，通过MQTT传输分片，接收端集齐所有分片后重组为完整文件，传输过程中如果出现分片丢失，仅需要重传对应分片即可，容错成本极低
• 方案二：MQTT仅负责传输控制信令，大文件通过HTTP/HTTPS、FTP等专门用于文件传输的协议进行传输，文件传输完成后再通过MQTT发送通知给接收方，两种协议各司其职，整体传输效率、可靠性都要远高于直接用MQTT传大文件。

内容的提问来源于stack exchange，提问作者John