Raspberry Pi重连后Paho MQTT Client批量发送消息而非逐个的问题

我之前也碰到过一模一样的情况——正常运行时消息能逐个发布，但Pi离线重连后，Paho客户端就一股脑把本地缓存的消息全发出去了。这主要是因为Paho默认的消息发送逻辑或者咱们的离线消息推送流程没做速率控制，下面给你几个靠谱的解决办法：

1. 利用发布回调实现逐条发送（最可靠） #

核心思路是：不要一次性把所有本地消息都塞给客户端，而是发完一条，等确认成功后再发下一条。Paho的on_publish回调可以帮我们实现这个逻辑，确保每一条消息都得到确认后，再推送下一条。

示例代码大概是这样：

import paho.mqtt.client as mqtt
import sqlite3

# 全局变量：本地数据库连接，标记是否还有待发消息
db_conn = sqlite3.connect('sensor_data.db')
has_pending_messages = True

def on_connect(client, userdata, flags, rc):
    if rc == 0:
        print("Connected to VPS broker")
        # 连接成功后，启动第一条离线消息的发送
        send_next_message(client)
    else:
        print(f"Connection failed with code {rc}")

def on_publish(client, userdata, mid):
    # 消息发布成功后，标记这条消息为已发送，然后触发下一条发送
    mark_message_as_sent(userdata)  # 你需要实现这个函数，根据消息ID更新数据库状态
    send_next_message(client)

def send_next_message(client):
    global has_pending_messages
    # 从数据库按时间顺序取一条未发送的消息
    cursor = db_conn.cursor()
    cursor.execute("SELECT id, topic, payload, qos FROM pending_messages WHERE sent = 0 ORDER BY timestamp ASC LIMIT 1")
    row = cursor.fetchone()
    if row:
        msg_id, topic, payload, qos = row
        # 发布消息时把消息ID作为userdata传递，方便后续标记
        client.publish(topic, payload, qos=qos, userdata=msg_id)
    else:
        has_pending_messages = False
        print("All pending messages sent successfully")

# 初始化客户端
client = mqtt.Client()
client.on_connect = on_connect
client.on_publish = on_publish

# 限制最大并发未确认消息数为1，强制逐条发送
client.max_inflight_messages_set(1)

# 连接VPS上的Broker
client.connect("your-vps-ip", 1883, 60)

client.loop_forever()

2. 限制客户端的并发未确认消息数 #

Paho客户端默认的max_inflight_messages是20，这意味着它可以同时发送20条未收到确认的消息。把这个值设为1，就能强制客户端等上一条消息得到确认后，再发送下一条：

client.max_inflight_messages_set(1)

这个设置一定要配合QoS 1或2使用，因为QoS 0没有送达确认机制，客户端还是会直接把所有消息塞进网络栈，根本不会等待。

3. 优化本地消息的读取逻辑 #

如果你之前是一次性把所有离线消息从数据库查出来，然后循环调用client.publish()，那客户端会把这些消息都加入发送队列，导致一次性发送。改成每次只查一条，发送成功后再查下一条，就能从根源上避免批量推送的问题。

关键注意点 #

• 优先使用QoS 1或2：QoS 0的消息没有确认环节，客户端会直接批量发送，无法控制速率。
• 不要依赖time.sleep()控速：网络延迟是不稳定的，固定延迟可能导致消息堆积或者发送过慢，用回调触发下一次发送才是最可靠的方式。

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