Paho Go MQTT客户端消费消息存在10条/秒速率上限如何排查

按照你给出的现象——阈值前生产消费曲线完全贴合，阈值后速率稳定锁死在600条/分钟（10条/秒），和流量突增、网络抖动的随机波动特征完全不符，按优先级从高到低排查以下点：

• 第一优先级查消息回调的阻塞问题
  Paho Go客户端的消息回调默认串行执行，只要你在OnMessage回调里同步做了耗时稳定在100ms的操作（比如慢SQL写入、同步调用第三方接口、串行写本地日志），就会刚好卡10条/秒的吞吐。先做个最小验证：把回调里所有业务逻辑全删掉，只做原子计数，跑5分钟看消费速率能不能突破阈值。如果能，问题就出在业务处理逻辑，你要么把回调里的耗时逻辑扔到异步goroutine池处理，要么调大Paho客户端的消息处理并发数。
  注意别漏查日志配置：如果你开了同步刷日志的配置，单条日志刷盘耗时100ms的话，刚好会打出这个速率阈值。

• 第二优先级查Paho客户端的隐性参数配置
  别只扫基础连接配置，重点查两个容易漏的参数：

  • MaxInflight：QoS1/QoS2场景下，客户端默认最多允许10条未收到ACK的消息在途，如果你回调里ACK发的慢，或者网络RTT稳定在100ms，窗口打满后速率会直接锁死在MaxInflight / RTT，刚好就是10条/秒，把这个值调到1000以上再测。
  • OrderMatters：这个参数默认是true，会强制同一个主题的消息按顺序串行处理，直接锁死单主题消费并发为1，只要单条处理有耗时，立刻就会出吞吐上限。

• 第三优先级查MQTT Broker侧的限流配置
  不要默认Broker没有默认限流：

  • 查Broker的单客户端连接限流规则，10条/秒是很多开源MQTT Broker（EMQX、Mosquitto等）默认的测试环境单客户端限流阈值，看Broker后台对应连接的监控有没有触发限流的计数。
  • 查Broker的持久化配置，如果开了每条消息同步落盘，且磁盘IO性能差到单条落盘100ms，单客户端消费速率也会卡在这个值。

• 第四优先级查链路层限流
  用同节点的mosquitto_sub命令行工具订阅同一个主题，用压测工具往主题打超过10条/秒的消息，如果命令行工具消费也卡10条/秒，就是链路问题：查云服务器安全组、防火墙、运营商有没有对MQTT 1883/8883端口做小包速率限制，临时换个端口测试就能验证。

相关监控参考：

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