排查MQTT持久化中消息大量重复原因及非QOS2解决方案咨询
我来帮你拆解这个问题——你在QoS 1的发布订阅模式下测试MQTT持久化，遇到mosquitto.db里有5-7倍于预期的重复消息，最终导致订阅者重连时Broker因负载过高宕机，这个情况核心原因出在Broker的 inflight消息配置和QoS 1的重发机制的配合上，下面给你详细分析和可行的解决方案：
问题根源分析
首先看你的场景：发布者P1以1k条/秒的速率发消息，订阅者S1断开1小时后用相同ClientID重连。理想情况下应该存储360万条消息，但实际是5-7倍，这说明发布者一直在重复发送相同的消息，而Broker把这些重复消息都持久化了。
为什么会重复发？看你的配置里max_inflight_messages 1——这个参数限制了Broker同时处理的未确认（inflight）消息数量为1。对于每秒1k条的发布速率来说，这个值太小了：Broker每次只能处理1条消息，剩下的消息都在队列里排队，发布者因为迟迟收不到Broker的ACK，会触发QoS 1的重发机制，不断重复发送相同的消息，这些重复消息都会被Broker持久化到mosquitto.db里，最终导致消息量暴涨。
另外，虽然你的max_queued_messages设到了100万足够大，但inflight的瓶颈没解决，发布者的重发就停不下来，重复消息只会越堆越多。
具体解决方案
1. 调整Broker的max_inflight_messages参数
这是最核心的修复点：把max_inflight_messages调大，比如设置为100（可以根据你的Broker硬件性能调整，比如CPU、内存足够的话可以设到200甚至更高）。这样Broker可以同时处理更多的未确认消息，能更快给发布者返回ACK，从根源上减少发布者的重发次数，避免重复消息堆积。
2. 优化发布端的重发逻辑
检查你使用的MQTT发布客户端配置，比如：
- 调整重发间隔，不要设置过短，避免短时间内大量重复发送同一消息；
- 确保客户端正确处理Broker返回的ACK，不要在未收到ACK时无限制重发（比如设置合理的重发次数上限）。
3. 优化Broker的持久化配置
- 开启
autosave_on_changes false（你的配置里注释掉了），改为仅按autosave_interval 30定期保存持久化数据。这样可以减少Broker因为每收到一条消息就写磁盘的IO开销，避免在消息大量堆积时磁盘IO成为瓶颈； - 如果条件允许，把mosquitto.db放到SSD存储上，提升磁盘读写性能，缓解持久化时的负载压力。
4. 订阅端重连时做流量控制
订阅者S1重连时，Broker会批量推送堆积的消息，这时候可以：
- 在订阅端的MQTT客户端配置里设置
max_inflight_messages，控制每次接收的消息数量，避免Broker一次性推送所有堆积消息导致瞬间负载过高； - 让订阅者重连后先以较低的速率消费消息，逐渐提升消费速度，给Broker足够的缓冲时间。
5. 可选：调整会话持久化策略（如果业务允许）
如果你的业务场景不需要严格的会话持久化（即断开后不需要接收离线期间的所有消息），可以考虑让订阅者使用非持久化会话（clean session=true），但这会丢失离线期间的消息，需要根据业务需求权衡。
调整后的参考配置
修改关键参数后的配置示例：
pid_file /var/run/mosquitto.pid # 调大inflight消息数，适配高发布速率 max_inflight_messages 100 persistence true persistence_file mosquitto.db persistence_location /var/lib/mosquitto/ log_dest file /var/log/mosquitto/mosquitto.log include_dir /etc/mosquitto/conf.d password_file /etc/mosquitto/passwd allow_anonymous false max_queued_messages 1000000 autosave_interval 30 # 关闭随改随存，减少磁盘IO autosave_on_changes false
补充说明
QoS 2确实能保证消息仅送达一次，但它的握手机制会带来更高的性能开销，所以调整QoS 1的相关参数是更高效的解决方案。只要解决了Broker inflight消息数的瓶颈，发布者的重发次数会大幅减少，mosquitto.db里的重复消息问题就能得到解决，进而避免重连时Broker崩溃的情况。
内容的提问来源于stack exchange，提问作者Sindhu Raju
