配置代理 MQTT 客户端选项

重要

此设置要求修改 Broker 资源。 它仅在初始部署时使用 Azure CLI 或 Azure 门户进行配置。 如果需要 Broker 配置更改,则需要新的部署。 若要了解详细信息,请参阅自定义默认代理

MQTT 代理高级客户端选项控制代理与 MQTT 客户端的交互方式。 这些设置在连接期间由代理和客户端进行协商,包括会话过期、消息过期、最大接收值和保持连接。 特定于 Azure IoT 操作的唯一设置是订阅服务器队列限制

有关可用设置的完整列表,请参阅 ClientConfig API 参考。

在许多情况下,默认客户端设置就足够了。 若要替代 MQTT 代理的默认客户端设置,请编辑 Broker 资源中的 advanced.clients 部分。 目前,只有在使用 --broker-config-file 命令部署 IoT 操作时使用 az iot ops create 标志才能支持此替代。

若要开始,请准备 JSON 格式的 Broker 配置文件,如下例所示:

{
  "advanced": {
    "clients": {
      "maxSessionExpirySeconds": 282277,
      "maxMessageExpirySeconds": 1622,
      "subscriberQueueLimit": {
        "length": 1000,
        "strategy": "DropOldest"
      },
      "maxReceiveMaximum": 15000,
      "maxKeepAliveSeconds": 300
    }
  }
}

然后,使用带有 az iot ops create 标志的 --broker-config-file 命令部署 IoT 操作,如下命令所示。 (为简洁起见,省略了其他参数。)

az iot ops create ... --broker-config-file <FILE>.json

要了解更多信息,请参阅用于高级 MQTT 代理配置的 Azure CLI 支持代理示例

订阅服务器队列限制

MQTT 代理会为包含等待传递的 QoS 1 消息的每个订阅服务器保留一个队列。 收到来自发布者的消息后,会将其添加到此队列中。 会在它们在传递后将其移除,并由订阅者通过 PUBACK 消息确认。 如果消息到达的速度比订阅服务器确认的速度快,或者订阅服务器由于持久会话而处于离线状态,队列可能会变大。

MQTT 代理可以将这些消息缓冲到磁盘以节省内存,但此策略有时这不足以解决问题。 可能未设置磁盘缓冲区,或者可能由于其他订阅者而已满。 因此,订阅服务器队列限制有助于防止代理对单个订阅服务器使用过多内存。

订阅服务器队列限制有两个设置:

  • 长度:单个订阅服务器可以排队的最大消息数。 如果队列已满并且有新消息到达,代理将根据配置的策略删除该消息。

  • 策略:队列已满时要使用的策略。 这两种策略包括:

    • 无:除非会话过期,否则不会删除消息,队列可以无限制地增长。 此选项为默认行为。
    • DropOldest:删除队列中最早的消息。

限制仅适用于订阅者的传出队列,其保留由于正在进行的队列已满而未分配数据包 ID 的消息。 此限制不适用于正在处理的队列。

由于限制是针对每个后端分区应用的,MQTT 代理无法保证整个群集中订阅者的传出消息总数。 例如,将长度设置为 10,000 并不意味着订阅者最多接收 10,000 条消息。 它最多可以接收 10,000 * number of partitions * number of backend workers 条消息。

慢速订阅服务器

慢速订阅服务器是无法跟上传入消息速率的订阅服务器。 如果订阅者处理消息缓慢、已断开连接或离线,则可能会出现此问题。 订阅服务器队列限制有助于防止慢速订阅服务器消耗过多内存。

消息过期

maxMessageExpirySeconds 设置会控制消息在过期之前可以停留在队列中的时长。 如果消息在队列中停留的时间超过最大过期时间,则标记为已过期。 但是,过期的消息只有在到达队列的开头时才会遭放弃。 这种被动过期机制有助于管理内存使用情况,确保旧消息最终会被删除。

会话过期

maxSessionExpirySeconds 设置与订阅服务器队列限制配合使用,以确保消息不会无限期地保留在队列中。 如果会话过期,该会话队列中的所有消息都将被删除。 这种做法有助于通过最终清除整个队列来防止离线订阅者使用过多内存。

消息过期和会话过期对于管理慢速和离线订阅服务器以及确保高效的内存使用都很重要。