你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
配置代理 MQTT 客户端选项
重要
此设置需要修改代理资源，并且只能在初始部署时使用 Azure CLI 或 Azure 门户进行配置。 如果需要 Broker 配置更改，则需要新的部署。 若要了解详细信息，请参阅自定义默认代理。
代理高级客户端选项控制代理与 MQTT 客户端的交互方式。 这些设置在连接期间由代理和客户端进行协商，包括会话过期、消息过期、最大接收值和保持连接。 特定于 Azure IoT 操作的唯一设置是订阅服务器队列限制。
可在 ClientConfig API 参考中找到可用设置的完整列表。
在许多情况下，默认客户端设置就足够了。 若要替代代理的默认客户端设置，请编辑“代理”资源中的 advanced.clients 部分。 目前，仅支持在使用 az iot ops create 命令部署 Azure IoT 操作时，通过 --broker-config-file 标志来实现此替代。
若要开始操作，请准备 JSON 格式的“代理”配置文件，如以下示例所示：
{
"advanced": {
"clients": {
"maxSessionExpirySeconds": 282277,
"maxMessageExpirySeconds": 1622,
"subscriberQueueLimit": {
"length": 1000,
"strategy": "DropOldest"
},
"maxReceiveMaximum": 15000,
"maxKeepAliveSeconds": 300
}
}
}
然后，使用带有 --broker-config-file 标志的 az iot ops create 命令部署 Azure IoT 操作，如以下命令所示（为简洁起见，省略了其他参数）：
az iot ops create ... --broker-config-file <FILE>.json
要了解更多信息，请参阅用于高级 MQTT 代理配置的 Azure CLI 支持和代理示例。
订阅服务器队列限制
MQTT 代理会为包含等待传递的 QoS 1 消息的每个订阅服务器保留一个队列。 从发布者收到消息后，会将消息添加到此队列中，并在消息送达并由订阅服务器通过 PUBACK 确认后删除将其删除。 如果消息到达的速度比订阅服务器确认的速度快，或者订阅服务器由于持久会话而处于离线状态，队列可能会变大。
代理可以将这些消息缓冲到磁盘以节省内存，但有时这不足以解决问题。 可能是未设置磁盘缓冲区，也可能是由于其他订阅服务器的原因磁盘已满。 因此，订阅服务器队列限制有助于防止代理对单个订阅服务器使用过多内存。
订阅服务器队列限制有两个设置：
长度：单个订阅服务器可以排队的最大消息数。 如果队列已满并且有新消息到达，代理将根据配置的策略删除该消息。
策略：队列已满时要使用的策略。 这两种策略包括：
无：除非会话过期，否则不会删除消息，队列可以无限制地增长。 这是默认行为。
DropOldest：删除队列中最早的消息。
该限制仅适用于订阅服务器的传出队列，其中包含由于处理中的队列已满而尚未分配数据包 ID 的消息。 此限制不适用于正在处理的队列。
由于限制是针对每个后端分区应用的，因此代理无法保证整个集群中订阅服务器的传出消息总数。 例如，将长度设置为 10,000 并不意味着订阅服务器最多会接收 10,000 条消息。 它最多可以接收 10,000 * number of partitions * number of backend workers 条消息。
慢速订阅服务器
慢速订阅服务器是无法跟上传入消息速率的订阅服务器。 如果订阅服务器处理消息的速度较慢、断开连接或处于脱机状态，则可能会出现这种情况。 订阅服务器队列限制有助于防止慢速订阅服务器消耗过多内存。
消息过期
maxMessageExpirySeconds 设置会控制消息在过期之前可以停留在队列中的时长。 如果消息在队列中停留的时间超过最大过期时间，则会将其标记为已过期。 但是，过期消息只有在到达队列开头时才会被丢弃。 这种被动过期机制有助于管理内存使用情况，确保旧消息最终会被删除。
会话过期
maxSessionExpirySeconds 设置与订阅服务器队列限制配合使用，以确保消息不会无限期地保留在队列中。 如果会话过期，该会话队列中的所有消息都将被删除。 通过最终清除整个队列，这有助于防止离线订阅服务器使用过多的内存。
消息过期和会话过期对于管理慢速和离线订阅服务器以及确保高效的内存使用都很重要。