Konfigurieren von Broker MQTT-Clientoptionen
Wichtig
Diese Einstellung erfordert das Ändern der Brokerressource und kann nur zur ersten Bereitstellungszeit mithilfe der Azure CLI oder des Azure-Portals konfiguriert werden. 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 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 Broker außer Kraft zu setzen, bearbeiten Sie den advanced.clients-Abschnitt in der Brokerressource. Derzeit wird diese Außerkraftsetzung nur mit dem --broker-config-file-Flag unterstützt, wenn Sie die Azure IoT-Vorgänge mit dem az iot ops create-Befehl bereitstellen.
Bereiten Sie zunächst eine Broker-Konfigurationsdatei im JSON-Format vor, z. B. im folgenden Beispiel:
{
"advanced": {
"clients": {
"maxSessionExpirySeconds": 282277,
"maxMessageExpirySeconds": 1622,
"subscriberQueueLimit": {
"length": 1000,
"strategy": "DropOldest"
},
"maxReceiveMaximum": 15000,
"maxKeepAliveSeconds": 300
}
}
}
Stellen Sie dann Azure IoT Operations mithilfe des az iot ops create-Befehls mit dem --broker-config-file-Flag bereit, z. B. den folgenden Befehl (andere Parameter, die aus Platzgründen weggelassen werden):
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 und nach der Zustellung und Bestätigung durch den Abonnenten mit einem PUBACK entfernt 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 Broker kann diese Nachrichten auf dem Datenträger puffern, um Arbeitsspeicher zu sparen, dies ist jedoch möglicherweise nicht immer ausreichend. Der Datenträgerpuffer ist möglicherweise nicht eingerichtet, oder er kann aufgrund anderer Abonnenten 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 die Standardeinstellung.
DropOldest: Die älteste Nachricht in der Warteschlange wird gelöscht.
Der Grenzwert gilt nur für die ausgehende Warteschlange des Abonnenten, 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 Broker die Gesamtzahl der ausgehenden Nachrichten für einen Abonnenten im gesamten Cluster nicht garantieren. Das Festlegen der Länge auf 10.000 bedeutet beispielsweise nicht, dass der Abonnent höchstens 10.000 Nachrichten empfängt. 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. Dies kann auftreten, wenn der Abonnent Nachrichten langsam verarbeitet, getrennt oder offline ist. 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 Offlineabonnenten 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.