MQTT断链重连后重复接收到最后一条消息

最新推荐文章于 2025-07-03 11:11:49 发布
最新推荐文章于 2025-07-03 11:11:49 发布
阅读量9.9k 收藏 4
点赞数 2
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/keybersan/article/details/83068525
探讨了MQTT协议中订阅端重复接收消息的问题，特别是在断开连接后重启时，如何避免接收到重复的消息。问题核心在于MqttMessage的Retained属性设置为true导致的消息保留机制，解决办法是将该属性设置回默认的false。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

MQTT推送消息订阅端重复接收问题。

（背景）订阅端断开的时候，发布端联系多次推送消息。

（现象）订阅端启动时，接收到最后一条推送消息有两次；即使Qos设置为2；依然是两次。

经排查是因为

MqttMessage的Retained设置为了true;
该值很多文章上只说了是 消息保留机制，若设置为true，mqtt服务器会保留每次发布的消息；较少提到
 若订阅某主题的客户端重启，则会把此主题之前发布的消息重新推送到客户端。

该值默认为false;去掉修改该值即可。

keybersan
关注
深入探究基于发布/订阅模式的轻量级消息传输协议 MQTT
dvlinker的技术专栏
10-13 2万+
深入探究基于发布 / 订阅模式的轻量级消息传输协议MQTT。
MQTT建立连接
Ryan爱吃糖的博客
03-18 5337
MQTT每次断连重连后重复接收到消息
wfanking的博客
01-17 2万+
问题：设备与服务器进行通信期间，不断重新配网。与嵌入式联调过程中发现每次取消订阅再重新订阅后，会重复接收到一条消息。 上图为Paho软件测试结果。MQTT测试软件下载地址 Paho：https://pan.baidu.com/s/1WkiR60EVz6LZQ-NNwyd6MQ mqtt.fx：https://pan.baidu.com/s/130giQTKQhwSp4qeWKisrrA 收到该条信...
MQTT每次断连重连后重复接收到消息-附件资源
03-05
MQTT每次断连重连后重复接收到消息-附件资源
MQ消息重复消费的原因、解决方案对比
最新发布
2301_79742544的博客
07-03 718
消息重复消费是很多系统都会碰到的麻烦事，本文先讲清楚为什么会重复，然后说说用 Redis 和消息确认（ACK）能不能解决问题，哪里还会出坑。最后给你介绍几个靠谱的解决方案，帮你保证消息不丢也不重复，让业务更稳更安全。
MQTT每次断连重连后重复接收到消息【retain属性】
zwj1030711290的优快云
11-19 524
Broker对保留消息的处理Broker会存储每个Topic的最后一条保留消息及其Qos，当订阅该Topic的客户端上线后，Broker需要将该消息投递给它。publish消息时，如果retain值是true，则服务器会一直记忆，哪怕是服务器重启。收到该条信息解析后解密发现此条信息为更换网络指令，故设备不停断网进行重新配网。联调过程中发现每次取消订阅再重新订阅后，会重复接收到一条消息。所以我们要解决的问题为：MQTT每次断连重连后重复接收到消息。问题：设备与服务器进行通信期间，不断重新配网。
mqtt客户端重连会接收到服务器保留的该主题消息
weixin_37460672的博客
05-21 2649
1.今天小伙伴使用mqtt客户端重连时发现每次都能接收到服务器保留的此主题最后一条消息，查了一下 2.mqtt服务端发送时defaultRetained设置为true保留消息，false不保留消息，即便是重启mqtt服务器消息仍会保留 3.我将defaultRetained设置为false后，或者不设置，因为默认时false，发现再发送消息确实不会保留了，但是客户端重连后发现仍会接收到true状态...
MQTT协议笔记之消息流
weixin_33709364的博客
07-13 273
前言 前面的笔记已把所有消息类型都过了一遍，这里从消息流的角度尝试解读一下。 网络故障 在任何网络环境下，都会出现一方连接失败，比如离开公司大门那一刻没有了WIFI信号。但持续连接的另一端-服务器可能不能立即知道对方已断开。类似网络异常情况，都有可能在消息发送的过程中出现，消息发送出去，就丢失了。 MQTT协议假定客户端和服务器端稳定情况一般，彼此之通信管道不可靠，一旦客户端网络断开，情况...
mqtt重复下发同一个消息id问题
qq_38240926的博客
06-22 8546
mqtt重复下发同一个消息id问题 一.问题描述与分析 最近在物联网项目开发中，mqtt服务器给我们设备推送消息时，概率性出现同一个消息id重复下发问题。通过使用wireshark抓包判断，得出结论是我们设备在收到服务器推送的消息后，没有立即给服务器回复ack造成的，下图为设备抓包log。 从log中分析，服务器向设备发送一个publish message消息后，我们设备回复publish ac...
消息重复问题
zhijingege的博客
05-20 1191
在消息传递过程中，如果出现传递失败的情况，发送发会执行重试，重试的过程就又可能会产生重复消息，对使用消息队列的业务系统来说，如果没有对重复消息进行处理，就又可能会导致系统数据出现错误。 消费重复的情况是必然存在 在MQTT协议中，给出了三种传递消息是提供的服务质量标准，这三种服务质量从低到高依次是： At most once:至多一次；在消息传递时，最多会被送达一次，换一个说法就是，没有什么消息可靠性保证，允许丢消息，一般都是一些对消息可靠性要求不高的监控场景使用，可以接受数据少量丢失。 At least
MQTT之重复消息（1、导致重复消息的因素）
zllww123的博客
03-27 1349
通过理解这些根本原因，可以针对性设计去重策略，在10万台设备规模下将重复消息率控制在0.1%以下。{"type":"batch", "messages":[...]} // 可能包含历史数据。/proc/sys/net/ipv4/tcp_retries2 = 15 # 默认重试次数。i++) { // 固定次数重试。@Scheduled(fixedRate = 300000) // 5分钟补偿。// 典型设备端重试代码（Arduino）// 可能被不同消费者实例处理。// 可能造成重复补发。
EMQX每次启动项目都会回调最后一条数据
zl761117410的专栏
08-09 522
EMQX
处理消费过程中的重复消息
weixin_30507481的博客
08-29 225
在消息传递过程中，如果出现传递失败的情况，发送方会执行重试，重试过程中就有可能产生重复的消息。如果没有对重复消息进行处理，就可能导致系统的数据出现错误。 比如，一个消费订单消息，统计下单金额的微服务，如果没有正确处理重复消息，那就会出现重复统计，导致统计结果错误。 一、消息重复的情况必然存在 在MQTT协议中，给出了三种传递消息时能够提供的服务质量标准： At most...
如何解决MQ的重复性消息
peace_dove的博客
05-24 2608
1：什么是MQ MQ即消息队列 message queue 2：重复消息是怎么回事 ① 消息生产者没有收到消息队列收到消息的应答，重试机制使得重复产生消息 比如网络故障导致应答消息丢失或者消息太多 ，应答消息传回受到阻塞，生产者等待超时 ②消息已经到达消息队列，但发送给消费者的时候，没有收到来自消费者的回复消息，或者消息中间件更改消息状态出现问题 3：如何解决消息重复 通过幂等操作：不论操作多少次，操作的结果是确定的。 例如：幂等：update tab set count=10 where id=2 非幂等
《消息队列高手课》如何处理消费过程中的重复消息？
weixin_44399827的博客
05-12 471
在消息传递过程中，如果出现传递失败的情况，发送方会执行重试，重试的过程中就有可能会产生重复的消息。对使用消息队列的业务系统来说，如果没有对重复消息进行处理，就有可能会导致系统的数据出现错误。 比如说，一个消费订单消息，统计下单金额的微服务，如果没有正确处理重复消息，那就会出现重复统计，导致统计结果错误。 你可能会问，如果消息队列本身能保证消息不重复，那应用程序的实现不就简单了？那有没有消息队列能保证消息不重复呢？ 消息重复的情况必然存在 在 MQTT 协议中，给出了三种传递消息时能够提供的服务质量标
MQTT协议会话中消息重发的思路实现（个人理解）
andGoodLuck的博客
12-16 1558
publish和pubrel的消息重发是针对订阅者而言的，重发是谁是发布者，才会担起这个责任，订阅者只是被动响应PUBACK、PUBREC或者PUBCOM。​ 实现方案：30s内收到pubrec时（入站read），取消对应的messageId的publish任务，​ 30s内收到pubcom时（入站read），取消messageId对应的pubrel任务。​ 实现方案：出站write时就要开启周期性（假设设定每30s）重发任务，
MQTT断线重连及订阅消息恢复
热门推荐
行知致简的专栏
03-01 6万+
MQTT断线重连及订阅消息恢复 工具 MQTT客户端是用的 pahohttp://www.eclipse.org/paho/ 问题 采用以下配置 connOpts = new MqttConnectOptions(); connOpts.setCleanSession(true); connOpts.setConnectionT...
解决 mqtt 诡异重复连接问题
不懂一休
08-12 3万+
以下问题为 阿里云 mqtt 使用过程中发现 一、首先贴出简单核心代码如下 client.on('connect', function () { client.publish('test/clientE', '' + (Math.random() * 10).toFixed(2), {'qos': 2, 'retain': true}, function (err) { if (err) { console.log(err) } else {
mqtt只有在同一个会话连接中才能订阅到topic吗？
03-19
<think>嗯，用户问的是MQTT是否只有在同一个会话连接中才能订阅到Topic。这个问题看起来他们可能遇到了订阅相关的问题，或者对MQTT的会话机制不太清楚。首先，我需要回顾一下MQTT协议的基础知识，特别是关于会话和订阅的部分。 MQTT的会话（Session）确实是一个关键概念。根据协议，客户端连接服务器时可以设置Clean Session标志。如果Clean Session为true，服务器不会保存任何之前的会话信息，每次连接都是全新的。相反，如果设为false，服务器会保留会话状态，包括订阅信息和未确认的消息。所以用户可能想知道，是否只有在同一个会话中订阅的Topic才能接收消息。 接下来，我需要考虑不同的情况。例如，如果客户端在断开后重新连接，并且Clean Session为false，之前的订阅是否仍然有效。根据协议，这种情况下服务器应该恢复之前的订阅，客户端不需要重新订阅。但如果是Clean Session为true，那么断开后订阅会丢失，必须重新订阅。用户的问题可能涉及这种情况，比如客户端重连后没有重新订阅，导致收不到消息。 另外，用户可能混淆了会话和连接的概念。一个会话可以跨越多个连接，只要客户端使用相同的Client ID并设置Clean Session为false。所以订阅的Topic实际上是与会话关联，而不是单个连接。这意味着即使断开后重新连接，只要会话保持，订阅依然有效。 还需要考虑QoS级别的影响。比如，如果订阅时使用了QoS 1或2，服务器会存储相应的订阅信息，即使断开连接，这些信息也会保留。但这也取决于Clean Session的设置。如果用户没有正确配置Clean Session，可能会导致订阅信息丢失。 可能用户遇到的情况是，他们在连接时使用了Clean Session为true，导致每次连接都是新的会话，之前的订阅不存在。所以当他们重新连接后，如果没有重新订阅，自然收不到消息。这时候需要检查客户端的连接参数，确保Clean Session设置正确。 此外，服务器端的配置也可能影响会话的持久性。有些服务器可能有会话超时设置，如果客户端长时间断开，会话可能会被清除。这时候即使Clean Session为false，也无法恢复订阅。需要确认服务器的配置是否允许会话保持足够长的时间。 总结来说，MQTT的订阅是与会话相关联的，而不是单个连接。只要会话存在（Clean Session为false），订阅就会保留，即使断开重连。如果Clean Session为true，每次连接都是新会话，需要重新订阅。用户的问题可能出在Clean Session的设置上，或者误解了会话和连接的关系。需要引导他们检查连接参数，确保正确使用Clean Session，并理解会话的生命周期。</think>### MQTT 订阅与会话的关系解析 MQTT **订阅（Subscription）** 的有效性取决于**会话（Session）** 的配置，但订阅本身并不仅限于单次连接。具体规则如下： --- #### **1. 会话（Session）的核心作用** MQTT 协议通过会话机制管理客户端状态，会话的生命周期由 `Clean Session` 标志控制： - **`Clean Session = true`** 每次连接均为**全新会话**，服务器不会保留任何订阅或未确认消息。 - **`Clean Session = false`** 服务器会保留会话状态（包括订阅、未确认的 QoS1/QoS2 消息），客户端重连后恢复原有状态。 --- #### **2. 订阅的持久性规则** | 场景 | 订阅是否保留 | 消息接收条件 | |------|-------------|--------------| | **首次连接（`Clean Session=true`）** | ❌ 断开后订阅失效 | 仅连接期间发布的消息 | | **重连（`Clean Session=false`）** | ✅ 订阅持续有效 | 可接收离线期间未消费的 QoS1/QoS2 消息 | | **跨连接订阅** | ❌ 需重新订阅（`Clean Session=true`） | 仅新订阅后发布的消息 | **关键结论**： - 若需**跨连接保留订阅**，必须设置 `Clean Session=false`。 - 若设置 `Clean Session=true`，每次连接均需重新订阅。 --- #### **3. 验证实验：订阅与会话的关联** **步骤 1：客户端首次订阅** 使用 `Clean Session=false` 连接并订阅 Topic： ```bash mosquitto_sub -t "test/topic" -q 1 -i "client_123" -c false ``` **步骤 2：断开并重新连接** 客户端断开后，服务器保留订阅。发布一条离线消息： ```bash mosquitto_pub -t "test/topic" -m "offline_msg" -q 1 ``` **步骤 3：客户端重新连接** 使用相同 Client ID 和 `Clean Session=false` 重新连接： ```bash mosquitto_sub -t "test/topic" -q 1 -i "client_123" -c false ``` 客户端将收到离线期间发布的 QoS1 消息。 --- #### **4. 常见问题与解决方案** **问题：重连后无法收到消息** - **原因 1**：客户端设置 `Clean Session=true`，导致订阅丢失。 **解决**：修改连接参数为 `Clean Session=false`。 - **原因 2**：服务器配置的会话超时（Session Expiry）过短。 **解决**：调整服务器会话超时时间（如 EMQX 的 `session_expiry_interval`）。 **问题：跨设备无法共享订阅** - **原因**：MQTT 订阅基于 Client ID 和会话，不同 Client ID 的订阅相互独立。 **解决**：使用共享订阅（Shared Subscription）或桥接（Bridge）实现跨设备消息分发。 --- #### **5. 会话管理的最佳实践** 1. **关键场景使用 `Clean Session=false`** - 需要离线消息接收时（如 IoT 设备断网重连）。 - 避免频繁重复订阅降低性能。 2. **合理设置会话超时** - EMQX 默认会话超时为 2 小时，可通过配置调整： ```bash # emqx.conf zone.external.session_expiry_interval = 24h ``` 3. **避免 Client ID 冲突** - 不同客户端使用唯一 Client ID，否则会导致会话覆盖。 --- ### **总结** MQTT **订阅的有效性依赖于会话配置**而非单次连接： - 通过 `Clean Session=false` 实现跨连接订阅持久化。 - 通过 QoS 等级控制离线消息可靠性。 - 需结合业务场景设计会话超时和 Client ID 策略。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值