为何Azure Service Bus Explorer创建IoT Hub监听器时显示大量旧消息？

嘿，Markus，我之前排查过类似的IoT Hub消息积压问题，刚好能给你梳理清楚来龙去脉和解决办法：

一、旧消息的可能来源 #

• 未完成的接收操作：IoT Hub底层依赖Event Hubs存储消息，默认1天保留期是针对已完成处理的消息，但如果你的接收端用了PeekLock模式接收消息后，没有调用Complete()/Abandon()/DeadLetter()，这些消息会一直处于"未完成"状态，哪怕超过1天保留期也不会被自动清除。
• 设备本地缓存补发：如果设备之前因为网络故障离线，很多设备SDK会自动把消息存在本地缓存，恢复联网后批量补发这些积压了数月的旧消息，刚好被你的监控捕获到。
• 路由转发的目标服务：如果你给IoT Hub配置了路由规则，把消息转发到Service Bus队列/主题，这些目标服务的保留期默认是7天（最长90天），旧消息可能是从这些转发目标里被监听到的——Service Bus Explorer能关联访问这些绑定的资源，容易混淆来源。

二、消息的存储位置 #

• IoT Hub底层Event Hubs存储：IoT Hub本身不做持久化，消息存在底层的Event Hubs分区里。未完成的消息会被标记为"待处理"，直到TTL过期或者被主动处理。
• 关联的Service Bus资源：如果用了路由转发，消息会存在对应的Service Bus队列/主题中，遵循该资源的保留期设置。
• 设备本地存储：设备端SDK的缓存机制会把未发送的消息存在设备本地（比如文件、内存或者嵌入式存储），直到发送成功或者缓存过期。

三、清除旧消息的具体操作 #

处理IoT Hub内置的未完成消息 #

• 用Service Bus Explorer批量处理：选中对应的Event Hub分区，选择接收消息后直接调用Complete操作，确认后这些消息会被永久移除；如果不需要保留，可以直接批量死信（DeadLetter），之后再清理死信队列。
• 检查接收端代码：确保所有接收的消息都能被正确完成或放弃，避免因为代码崩溃、逻辑漏洞导致消息一直处于未完成状态。

清理Service Bus转发目标的旧消息 #

• 在Service Bus Explorer中找到对应的队列/主题，使用Purge Messages功能批量删除所有积压消息。
• 调整Service Bus资源的保留期：在Azure门户里把保留期改成和IoT Hub一致的1天，防止未来再积压旧消息。
• 优化路由规则：添加过滤条件（比如按消息时间戳过滤），只转发近期的有效消息，避免旧消息被转发。

处理设备本地缓存的旧消息 #

• 联系设备开发团队：调整设备SDK的缓存策略，设置更短的本地缓存TTL，或者在消息发送成功后立即清除本地缓存。
• 发送设备孪生指令：如果设备支持远程控制，可以通过IoT Hub给设备发送指令，让它主动清理本地积压的旧消息。

内容的提问来源于stack exchange，提问作者Markus S.