Bereitstellungsplanung – Erweiterte MQTT-Optionen

Erweiterte MQTT-Optionen steuern, wie der MQTT-Broker mit Kunden interagiert. Diese Einstellungen werden beim Verbindungsaufbau zwischen dem Broker und dem Client ausgehandelt und umfassen Sitzungsablaufzeit, Nachrichtenablaufzeit, maximale Empfangsanzahl und Keep-Alive. Die einzige Einstellung, die für Azure IoT Einsatz spezifisch ist, ist der Grenzwert der Abonnentenwarteschlange. Entscheiden Sie vor der Bereitstellung, ob Sie diese Optionen anpassen müssen.

Important

Diese Optionen können nur bei der ersten Bereitstellung mithilfe des Azure CLI oder des Azure Portals konfiguriert werden. Um sie später zu ändern, müssen Sie sie erneut bereitstellen. Weitere Informationen finden Sie unter Anpassen des Standardbrokers.

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. Weitere Informationen finden Sie unter Azure CLI-Unterstützung für die erweiterte MQTT-Brokerkonfiguration.

Die vollständige Liste der verfügbaren Einstellungen finden Sie in der ClientConfig-API-Referenz.

Bereiten Sie zunächst eine Broker Konfigurationsdatei im JSON-Format vor. Beispiel:

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

Stellen Sie dann IoT-Vorgänge mithilfe des az iot ops create Befehls mit der --broker-config-file Kennzeichnung bereit. Andere Parameter werden aus Platzgründen weggelassen:

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

Maximale Paketgröße

Die Einstellung maxPacketSizeBytes steuert das größte MQTT-Paket, das der Broker von einem Client akzeptiert. Der Broker wirbt diesen Wert an MQTT v5-Kunden als Eigentum Maximum Packet Size im CONNACK-Paket an. Der Broker trennt Kunden, die größere Pakete senden.

Das Speicherprofil setzt eine obere Schranke für diesen Wert. Wenn Sie höher setzen maxPacketSizeBytes als das Speicherprofil erlaubt, verwendet der Broker stattdessen den Wert des Speicherprofils. Verwenden Sie diese Einstellung, um die Paketgrößen weiter zu begrenzen als das Speicherprofil, zum Beispiel um den Speicher in einer Bereitstellung zu schützen, die nur kleine Telemetriemeldungen verarbeitet.

Grenzwert der Abonnentenwarteschlange

Der MQTT-Broker führt für jeden Abonnenten eine Warteschlange für QoS-1-Nachrichten, die auf ihre Zustellung warten (Zustellung mindestens einmal). 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 Meldungen auf einem Datenträger puffern , um Arbeitsspeicher zu sparen, die Datenträgerpufferung ist jedoch nicht immer verfügbar. Der Datenträgerpuffer ist möglicherweise nicht konfiguriert, oder er ist aufgrund anderer Abonnenten bereits voll. Der Grenzwert der Abonnentenwarteschlange verhindert, dass ein einzelner Abonnent zu viel Brokerspeicher verbraucht.

Der Grenzwert der Abonnentenwarteschlange weist zwei Einstellungen auf:

  • Länge: Die maximale Anzahl von Nachrichten, die für einen Abonnenten in die Warteschlange gestellt werden können. Wenn die Warteschlange voll ist und eine neue Nachricht eingeht, legt der Broker eine Nachricht basierend auf der konfigurierten Strategie ab.

  • Strategie: Wie sich der Broker verhält, wenn die Warteschlange voll ist:

    • Keine (Standard): Nachrichten werden nicht gelöscht. Die Warteschlange kann bis zum Ablauf der Sitzung wachsen.
    • DropOldest: Der Broker legt die älteste Nachricht in der Warteschlange ab, um Platz für das neue zu schaffen.

Note

Der Grenzwert für die Abonnentenwarteschlange gilt für die ausgehende Warteschlange – Nachrichten, die auf das Senden an den Abonnenten warten. Die In-Flight-Warteschlange (Nachrichten, die gesendet, aber vom Abonnenten noch nicht bestätigt wurden) ist davon getrennt und wird durch die MQTT-Einstellung für das Empfangsmaximum gesteuert.

Important

In Bereitstellungen mit mehreren Partitionen skaliert die Anzahl der Warteschlangen pro Partition. Jede Partition verwaltet unabhängig voneinander eigene Abonnentenwarteschlangen. Der gesamte clusterweite Arbeitsspeicher, der von den Warteschlangen eines einzelnen Abonnenten verbraucht wird, kann übersteigen, was ein einzelner konfigurierter Grenzwert vorschlägt. Planen Sie die Arbeitsspeicherkapazität entsprechend für Bereitstellungen mit mehreren Partitionen.

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 maxMessageExpirySecondsals in der Warteschlange verbleibt, läuft sie ab. Der Broker löscht abgelaufene Nachrichten nicht aktiv – er verwirft sie, wenn sie die Front der Warteschlange erreichen. Diese passive Bereinigung sorgt dafür, dass die Speicherauslastung begrenzt bleibt, ohne die Warteschlange zu scannen.

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, verwirft der Broker alle Nachrichten in der Warteschlange für diese Sitzung. Das Ablaufen der Sitzung verhindert, dass Offline-Abonnenten unbegrenzt Speicher belegen, indem letztlich die gesamte Warteschlange geleert wird.

Maximale Nachrichtenablaufzeit und beibehaltene Nachrichten

In MQTT 5 respektieren beibehaltene Nachrichten das im Paket angegebene Ablaufintervall der PUBLISH Nachricht. Wenn ein Ablaufintervall festgelegt ist, wird die beibehaltene Nachricht entfernt, sobald das Intervall verstrichen ist. Wenn kein Intervall angegeben wird, bleibt die Nachricht unbegrenzt verfügbar.

Die Einstellung maxMessageExpirySeconds definiert eine globale Obergrenze für den Nachrichtenablauf, die für alle Nachrichten gilt, einschließlich der aufbewahrten. Wenn maxMessageExpirySeconds beispielsweise auf 1000 Sekunden festgelegt ist und eine beibehaltene Nachricht ein Ablaufintervall von 2000 Sekunden angibt, wird die Nachricht nach 1000 Sekunden entfernt.

Standardmäßig ist maxMessageExpirySeconds nicht festgelegt. In diesem Fall laufen aufbewahrte Nachrichten nicht ab, es sei denn, in der Nachricht wird explizit ein Ablaufintervall definiert.

Nächste Schritte

  • Last updated on