設定 Broker MQTT 用戶端選項
重要
此設定需要修改 Broker 資源，且只能在初始部署階段使用 Azure CLI 或 Azure 入口網站進行設定。 如果需要訊息代理程式設定變更，則需要新的部署。 若要深入瞭解，請參閱 自定義預設 Broker。
訊息代理程式進階客戶端選項可控制訊息代理程式與 MQTT 用戶端的互動方式。 這些設定會在連線期間交涉到訊息代理程式和用戶端，包括會話到期、訊息到期、接收上限，以及保持運作。 Azure IoT 作業特有的唯一設定是 訂閱者佇列限制。
如需可用設定的完整清單，請參閱 ClientConfig API 參考。
在許多情況下，預設客戶端設定就已足夠。 若要覆寫訊息代理程式的預設用戶端設定，請編輯 advanced.clients Broker 資源中的 區段。 目前，只有在您使用 命令部署 Azure IoT 作業az iot ops create時，才支援使用 --broker-config-file 旗標來覆寫。
若要開始使用，請以 JSON 格式準備 Broker 組態檔，如下列範例所示：
{
"advanced": {
"clients": {
"maxSessionExpirySeconds": 282277,
"maxMessageExpirySeconds": 1622,
"subscriberQueueLimit": {
"length": 1000,
"strategy": "DropOldest"
},
"maxReceiveMaximum": 15000,
"maxKeepAliveSeconds": 300
}
}
}
然後，使用 az iot ops create 命令搭配 --broker-config-file 旗標來部署 Azure IoT 作業，例如下列命令（為了簡潔而省略其他參數）：
az iot ops create ... --broker-config-file <FILE>.json
若要深入瞭解，請參閱 進階 MQTT 訊息代理程式組態 和 Broker 範例的 Azure CLI 支援。
訂閱者佇列限制
MQTT 訊息代理程式會針對等候傳遞的 QoS 1 訊息，為每個訂閱者保留佇列。 從發行者接收訊息並移除之後，訂閱者會透過 PUBACK傳遞並認可訊息，並新增至此佇列。 如果訊息送達的速度比訂閱者快，或者如果訂閱者使用持續性會話脫機，佇列可能會成長很大。
訊息代理程式可以將 這些訊息緩衝到磁碟 以節省記憶體，但這可能不一定足夠。 磁碟緩衝區可能未設定，或可能是因為其他訂閱者而已滿。 因此，訂閱者佇列限制有助於防止訊息代理程序針對單一訂閱者使用太多記憶體。
訂閱者佇列限制有兩個設定：
長度：可以針對單一訂閱者排入佇列的訊息數目上限。 如果佇列已滿且新的訊息送達，訊息代理程式會根據設定的策略卸除訊息。
策略：佇列已滿時要使用的策略。 這兩種策略如下：
無：除非會話到期，否則不會卸除訊息，而且佇列可以無限期成長。 此為預設行為。
DropOldest：卸除佇列中最舊的訊息。
限制僅適用於訂閱者的傳出佇列，此佇列會保留尚未指派封包標識碼的訊息，因為內部佇列已滿。 此限制不適用於正式發行前小眾測試佇列。
由於每個 後端分割區會套用限制，因此訊息代理程式無法保證整個叢集訂閱者的傳出訊息總數。 例如，將長度設定為 10,000 並不表示訂閱者最多會收到 10,000 則訊息。 相反地，它最多可以接收 10,000 * number of partitions * number of backend workers 訊息。
慢速訂閱者
緩慢的訂閱者是無法跟上傳入訊息速率的訂閱者。 如果訂閱者處理訊息的速度緩慢、已中斷連線或離線，就會發生這種情況。 訂閱者佇列限制有助於防止緩慢的訂閱者耗用太多記憶體。
訊息到期
此 maxMessageExpirySeconds 設定可控制訊息在到期前可留在佇列中的時間長度。 如果訊息在佇列中停留的時間超過到期時間上限，則會將其標示為已過期。 不過，只有在訊息到達佇列開頭時，才會捨棄過期的訊息。 此被動過期機制可藉由確保最終移除舊的訊息，協助管理記憶體使用量。
會話到期
此 maxSessionExpirySeconds 設定可與訂閱者佇列限制搭配運作，以確保訊息不會無限期地保留在佇列中。 如果會話到期，則會卸除該會話佇列中的所有訊息。 這有助於藉由清除整個佇列，防止離線訂閱者使用太多記憶體。
訊息到期和會話到期對於管理緩慢和離線訂閱者以及確保有效率的記憶體使用量都很重要。