Konfigurieren von Broker MQTT-Clientoptionen
Wichtig
Für diese Einstellung müssen Sie die Brokerressource ändern. Sie ist nur bei der ersten Bereitstellung mithilfe der Azure CLI oder des Azure-Portals konfiguriert. Eine neue Bereitstellung ist erforderlich, wenn Änderungen an der Broker-Konfiguration erforderlich sind. Weitere Informationen finden Sie unter Anpassen des Standardbrokers.
Die erweiterten Clientoptionen des MQTT-Brokers steuern, wie der Broker mit MQTT-Clients interagiert. Diese Einstellungen, die zwischen dem Broker und dem Client während der Verbindung ausgehandelt werden, umfassen Sitzungsablauf, Nachrichtenablauf, maximale Anzahl empfangen und Keepalive. Die einzige Einstellung, die für Azure IoT Operations spezifisch ist, ist der Grenzwert der Abonnentenwarteschlange.
Die vollständige Liste der verfügbaren Einstellungen finden Sie in der ClientConfig-API-Referenz.
In vielen Szenarien sind die Standardclienteinstellungen ausreichend. Um die Standardclienteinstellungen für den MQTT-Broker außer Kraft zu setzen, bearbeiten Sie den advanced.clients-Abschnitt in der Brokerressource. Derzeit wird diese Außerkraftsetzung nur mit dem Flag --broker-config-file unterstützt, wenn Sie IoT Einsatz mit dem Befehl az iot ops create bereitstellen.
Bereiten Sie zunächst eine Broker-Konfigurationsdatei im JSON-Format vor, etwa wie im folgenden Beispiel:
{
"advanced": {
"clients": {
"maxSessionExpirySeconds": 282277,
"maxMessageExpirySeconds": 1622,
"subscriberQueueLimit": {
"length": 1000,
"strategy": "DropOldest"
},
"maxReceiveMaximum": 15000,
"maxKeepAliveSeconds": 300
}
}
}
Stellen Sie dann IoT Einsatz mithilfe des Befehls az iot ops create mit dem Flag --broker-config-file bereit, wie beim folgenden Befehl. (Andere Parameter werden aus Platzgründen weggelassen.)
az iot ops create ... --broker-config-file <FILE>.json
Weitere Informationen finden Sie unter Azure CLI-Unterstützung für erweiterte MQTT-Brokerkonfigurationen und Brokerbeispiele.
Grenzwert der Abonnentenwarteschlange
Der MQTT-Broker hat eine Warteschlange für jeden Abonnenten mit QoS 1-Nachrichten, die auf die Zustellung warten. Nachrichten werden dieser Warteschlange hinzugefügt, wenn sie vom Herausgeber empfangen werden. Sie werden entfernt, nachdem sie zugestellt und von Abonnierenden mit einer PUBACK-Nachricht bestätigt wurden. Wenn Nachrichten schneller eingehen als der Abonnent sie bestätigen kann oder wenn der Abonnent mit einer persistenten Sitzung offline ist, kann die Warteschlange groß werden.
Der MQTT-Broker kann diese Nachrichten auf dem Datenträger puffern, um Arbeitsspeicher zu sparen, diese Taktik ist jedoch möglicherweise nicht immer ausreichend. Der Datenträgerpuffer ist möglicherweise nicht eingerichtet, oder er kann aufgrund anderer Abonnierenden voll sein. Daher verhindert der Teilnehmerwarteschlangengrenzwert, dass der Broker für einen einzelnen Abonnenten zu viel Arbeitsspeicher verwendet.
Der Grenzwert der Abonnentenwarteschlange weist zwei Einstellungen auf:
Länge: Die maximale Anzahl von Nachrichten, die für einen einzelnen Abonnenten in die Warteschlange gestellt werden können. Wenn die Warteschlange voll ist und eine neue Nachricht eingeht, legt der Broker die Nachricht basierend auf der konfigurierten Strategie ab.
Strategie: Die Strategie, die verwendet werden soll, wenn die Warteschlange voll ist. Die beiden Strategien sind:
- Keine: Nachrichten werden erst verworfen, wenn die Sitzung abläuft, und die Warteschlange kann unbegrenzt wachsen. Dies ist das Standardverhalten.
- DropOldest: Die älteste Nachricht in der Warteschlange wird gelöscht.
Der Grenzwert gilt nur für die ausgehende Warteschlange der Abonnierenden, die Nachrichten enthält, denen keine Paket-IDs zugewiesen wurden, weil die In-Flight-Warteschlange voll ist. Dieser Grenzwert gilt nicht für die In-Flight-Warteschlange.
Da der Grenzwert pro Back-End-Partition angewendet wird, kann der MQTT-Broker die Gesamtzahl der ausgehenden Nachrichten für Abonnierende im gesamten Cluster nicht garantieren. Das Festlegen der Länge auf 10.000 bedeutet beispielsweise nicht, dass Abonnierende höchstens 10.000 Nachrichten empfangen. Stattdessen könnte sie bis zu 10,000 * number of partitions * number of backend workers Nachrichten empfangen.
Langsame Abonnenten
Ein langsamer Abonnent ist einer, der nicht mit der Geschwindigkeit an eingehenden Nachrichten schritthalten kann. Dieses Problem kann auftreten, wenn Abonnierende Nachrichten langsam verarbeiten, getrennt oder offline sind. Der Grenzwert der Abonnentenwarteschlange verhindert, dass ein langsamer Abonnent zu viel Arbeitsspeicher verbraucht.
Ablauf der Nachricht
Die maxMessageExpirySeconds-Einstellung steuert, wie lange eine Nachricht in der Warteschlange verbleiben kann, bevor sie abläuft. Wenn eine Nachricht länger als die maximale Ablaufzeit in der Warteschlange bleibt, wird sie als abgelaufen markiert. Abgelaufene Nachrichten werden jedoch nur verworfen, wenn sie den Anfang der Warteschlange erreichen. Dieser passive Ablaufmechanismus hilft beim Verwalten der Speicherauslastung, indem sichergestellt wird, dass alte Nachrichten schließlich entfernt werden.
Sitzungsablauf
Die maxSessionExpirySeconds-Einstellung funktioniert mit dem Grenzwert der Abonnentenwarteschlange, um sicherzustellen, dass Nachrichten nicht unbegrenzt in der Warteschlange aufbewahrt werden. Wenn eine Sitzung abläuft, werden alle Nachrichten in der Warteschlange für diese Sitzung gelöscht. Dadurch wird verhindert, dass Offlineabonnierende zu viel Arbeitsspeicher verwenden, indem schließlich die gesamte Warteschlange gelöscht wird.
Sowohl ablaufende Nachrichten als auch der Ablauf der Sitzung sind wichtig für die Verwaltung langsamer und Offlineabonnents und für eine effiziente Speicherauslastung.