使用通配符的方式与普通方式订阅主题性能有多大区别

之前使用普通方式,订阅主题数过多对内存有要求,在使用通配符方式后,出现了处理不完消息的情况,请问下有什么解决办法

区别蛮大的,不过建议结合自己的场景自己测试一下。
一个客户端不建议订阅超过 20 个主题,来保持让它的消息速率小于 1500 个/ 秒

  • 精细化通配符匹配,减少不必要的订阅
  • 使用更具体的主题层级
  • 考虑分层订阅,避免过于宽泛的通配符

优化示例:

假设我们有一个物联网系统,包含多个传感器和设备,主题结构可能如下:

原始通配符订阅(不推荐):

topic: sensor/#

这种订阅会匹配所有sensor下的所有子主题,可能导致大量不相关消息被接收。

优化后的主题订阅策略:

  1. 精细化主题匹配
# 替代 sensor/#
sensor/temperature/+/status  # 只接收温度传感器状态
sensor/humidity/+/data       # 只接收湿度传感器数据
  1. 分层订阅示例
# 按设备类型订阅
sensor/temperature/room1/#   # 仅订阅1号房间温度相关信息
sensor/temperature/room2/#   # 仅订阅2号房间温度相关信息

# 按功能订阅
sensor/+/room1/status        # 订阅1号房间所有传感器状态
sensor/+/room2/alert         # 订阅2号房间所有告警信息
  1. 更具体的主题层级
# 不推荐
device/#

# 推荐
device/type/+/id/status      # 按设备类型和ID精确订阅
device/type/sensor/+/data    # 仅订阅传感器数据

这些策略可以:

  • 减少不必要的消息接收
  • 降低内存消耗
  • 提高消息处理效率
  • 简化消息路由