MQTT中还有一个情况，从上周三开始一直提示我们订阅数过多的预警，我们检查mqtt，发现只建立的约

理论上微消息队列MQTT版每个客户端最多允许同时订阅30个Topic，超过该限制会导致无法新增新的订阅关系。那么从你的描述6个client来算的话也就180个订阅关系。计算订阅Topic数量时，一个包含通配符的订阅计算为一个订阅数量；同一父级Topic下不同子级的Topic订阅被计算为不同的Topic数量。例如：A/#被计算为一个订阅数量。A/#和A/a1/#被计算为2个Topic订阅数量。如果你的业务代码没有重复订阅的逻辑问题的话，那么建议咨询一下MQTT技术支持团队钉钉群号：35228338

存在的原因可能是之前离线订阅数过多。clean session为false的订阅为离线订阅，即使客户端下线的情况下，订阅依然存在。对于离线订阅，和客户端的上下线关系不大。或者你们还可能配置了的订阅关系清理，订阅关系清理会每隔一段时间自动清理不使用的离线订阅。这个我们统计问题，我们发布修复一下，此回答整理自钉群“阿里云 微消息队列 MQTT产品咨询群”

MQTT协议中的订阅关系数过多可能是由于以下原因导致：

客户端连接过多，每个客户端都建立了大量的订阅关系，导致总量过大。您所说的 "只建立了约6个client连接" 似乎不会导致这样的问题。

某些代码逻辑错误或配置参数异常，在订阅/取消订阅消息时出现重复订阅、漏订等问题。例如，某些应用程序处理订阅时错误地将主题设置为通配符（例如＃或+），从而订阅了太多消息。

部分客户端未正确取消订阅或断开连接，在被动关闭时仍然保持了订阅状态。这种情况很难检测，因为有些MQTT服务器可能会自动清除未活跃者，但有些则会保留它们的记录。

相关MQTT服务商对订阅和连接数设置的限制或算法发生了变化, 导致策略与之前不同而报错警告。

针对以上情况，可以通过以下方式进行排查和处理：

根据日志记录或追踪工具分析每个客户端的订阅关系数量，并检查是否存在订阅重复或意外添加的情况。

确保每个客户端在断开连接或取消订阅后都能很好地清理其记录，并确保不会出现漏掉某些订阅或主题。

尝试通过MQTT服务器提供的管理界面或接口，查看当前连接和订阅关系的数量和状态，以便准确诊断问题所在。

如果无法确定具体原因，请联系MQTT服务商或相关技术支持团队。