Kubernetes部署单实例Thingsboard通过MQTT向Google PubSub发送消息时出现消息丢失问题原因排查

先直接给你个结论：单实例部署不一定是直接元凶，但确实可能是潜在风险点之一，更多时候消息丢失是多环节问题叠加的结果，咱们逐一拆解：

• 单点故障风险：如果这个单实例意外重启（比如K8s节点调度、资源不足被驱逐、应用崩溃），重启过程中正在处理的MQTT消息或者待发送到PubSub的消息可能直接丢失——除非你给Thingsboard配置了持久化存储（比如PostgreSQL、Cassandra）来缓冲这些消息。要是没开持久化，内存里的未处理消息重启后就没了。
• 资源瓶颈限制：单实例的CPU、内存如果被打满，会导致消息处理速度跟不上，要么消息堆积后被自动丢弃，要么MQTT客户端因为超时断开重连，中间的消息大概率会丢。尤其是高并发场景下，单实例的处理能力上限很容易被触达。

• MQTT QoS配置不合理：
  • 如果你的MQTT客户端用的是QoS 0（最多一次），那网络波动、代理或Thingsboard暂时不可用时，消息丢失是预期行为，这个锅得QoS配置背。
  • 即使用了QoS 1/2，也要确认Thingsboard的MQTT broker是否正确配置了消息持久化，否则重启后未确认的消息还是会丢。
• Thingsboard到Google PubSub的配置疏漏：
  • 检查是否开启了PubSub的消息重试机制，如果没开，当PubSub暂时不可用时，Thingsboard可能直接把消息扔了。
  • 确认PubSub的主题是否存在、权限配置是否正确（比如Thingsboard用的服务账号有没有发布消息的权限），权限不足时消息往往是被静默丢弃的，连报错都不一定有。
• Kubernetes层面的坑：
  • Pod优雅停机没配置：如果K8s对Pod做滚动更新、驱逐，但没给Thingsboard设置优雅停机时间，它可能来不及处理完正在发送的消息就被杀死，导致消息丢失。
  • 网络问题：K8s集群内部或者集群到Google PubSub的网络有丢包、延迟过高的情况，消息在传输途中直接“失踪”。
• 消息积压与超时：
  • 如果PubSub的订阅者消费速度跟不上，导致主题消息堆积，超过PubSub默认的7天保留期限，旧消息会被自动删除。
  • Thingsboard内部的消息队列如果设置了过短的超时时间，超过时间未处理的消息可能被直接丢弃。
• Thingsboard自身配置问题：
  • 去翻thingsboard.yml里关于消息转发、持久化的配置，比如是否开启了queue的持久化，是否设置了合理的消息重试次数，这些配置漏了很容易丢消息。

• 先看单实例的资源情况：在K8s里跑kubectl top pod <thingsboard-pod-name>，看看CPU、内存使用率是不是持续偏高，要是的话先扩容资源或者考虑多实例部署试试。
• 检查MQTT客户端的QoS设置，改成QoS 1再验证，看看丢消息的情况有没有缓解。
• 扒Thingsboard的日志：用kubectl logs <thingsboard-pod-name>找有没有关于PubSub发送失败、消息丢弃的报错信息，日志里往往藏着真相。
• 看Google PubSub的监控：查主题的发布成功率、消息堆积情况，确认是不是有请求被拒绝了。

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