Dela via

Konfigurera Asynkrona MQTT-klientalternativ

  • Artikel

Viktigt!

Den här inställningen kräver att du ändrar Broker-resursen. Den konfigureras endast vid den första distributionen med hjälp av Azure CLI eller Azure Portal. En ny distribution krävs om konfigurationsändringar i Broker behövs. Mer information finns i Anpassa standard broker.

Avancerade klientalternativ för MQTT-koordinator styr hur asynkron meddelandekö interagerar med MQTT-klienter. De här inställningarna, som förhandlats mellan asynkron meddelandekö och klienten under anslutningen, inkluderar sessionsförfallodatum, meddelandeförfallodatum, maximalt mottagande och hålla vid liv. Den enda inställningen som är specifik för Azure IoT Operations är gränsen för prenumerantkö.

Den fullständiga listan över tillgängliga inställningar finns i referensen för ClientConfig API.

I många scenarier räcker standardklientinställningarna. Om du vill åsidosätta standardklientinställningarna för MQTT-koordinatorn advanced.clients redigerar du avsnittet i Broker-resursen. För närvarande stöds den här åsidosättningen --broker-config-file endast med hjälp av flaggan när du distribuerar IoT-åtgärder med hjälp az iot ops create av kommandot .

Kom igång genom att förbereda en Broker-konfigurationsfil i JSON-format, som i följande exempel:

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

Distribuera sedan IoT-åtgärder med hjälp az iot ops create av kommandot med --broker-config-file flaggan, till exempel följande kommando. (Andra parametrar utelämnas för korthet.)

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

Mer information finns i Azure CLI-stöd för avancerad MQTT-koordinatorkonfiguration och Broker-exempel.

Gräns för prenumerantkö

MQTT-mäklaren håller en kö för varje prenumerant med QoS 1-meddelanden som väntar på att levereras. Meddelanden läggs till i den här kön när de tas emot från utgivaren. De tas bort när de har levererats och bekräftats av prenumeranten med ett PUBACK-meddelande. Om meddelanden kommer snabbare än vad prenumeranten kan bekräfta, eller om prenumeranten är offline med en beständig session, kan kön bli stor.

MQTT-mäklaren kan buffras dessa meddelanden till disken för att spara minne, men den här taktiken kanske inte alltid räcker. Diskbufferten kanske inte har konfigurerats eller så kan den vara full på grund av andra prenumeranter. Därför hjälper gränsen för prenumerantkö till att förhindra att asynkron meddelandekö använder för mycket minne för en enskild prenumerant.

Gränsen för prenumerantkö har två inställningar:

  • Längd: Det maximala antalet meddelanden som kan placeras i kö för en enskild prenumerant. Om kön är full och ett nytt meddelande tas emot släpper mäklaren meddelandet baserat på den konfigurerade strategin.

  • Strategi: Den strategi som ska användas när kön är full. De två strategierna är:

    • Ingen: Meddelanden tas inte bort om inte sessionen upphör att gälla och kön kan växa på obestämd tid. Det här beteendet är standard.
    • DropOldest: Det äldsta meddelandet i kön tas bort.

Gränsen gäller endast för prenumerantens utgående kö, som innehåller meddelanden som inte har tilldelats paket-ID eftersom kön under flygning är full. Den här gränsen gäller inte för kön under flygning.

Eftersom gränsen tillämpas per serverdelspartition kan MQTT-koordinatorn inte garantera det totala antalet utgående meddelanden för en prenumerant i hela klustret. Om du till exempel anger längden till 10 000 betyder det inte att prenumeranten får högst 10 000 meddelanden. I stället kan den ta emot upp till 10,000 * number of partitions * number of backend workers meddelanden.

Långsamma prenumeranter

En långsam prenumerant är en som inte kan hänga med i den inkommande meddelandefrekvensen. Det här problemet kan uppstå om prenumeranten bearbetar meddelanden långsamt, kopplas från eller är offline. Gränsen för prenumerantkö förhindrar att en långsam prenumerant förbrukar för mycket minne.

Meddelandet upphör att gälla

Inställningen maxMessageExpirySeconds styr hur länge ett meddelande kan stanna i kön innan det upphör att gälla. Om ett meddelande stannar kvar i kön längre än den maximala förfallotiden markeras det som utgånget. Meddelanden som har upphört att gälla ignoreras dock endast när de når början av kön. Den här passiva förfallomekanismen hjälper till att hantera minnesanvändningen genom att se till att gamla meddelanden slutligen tas bort.

Sessionen upphör att gälla

Inställningen maxSessionExpirySeconds fungerar med gränsen för prenumerantkö för att säkerställa att meddelanden inte sparas i kön på obestämd tid. Om en session upphör att gälla tas alla meddelanden i kön för sessionen bort. Den här metoden hjälper till att förhindra att offlineprenumeranter använder för mycket minne genom att så småningom rensa hela kön.

Både förfallodatum för meddelanden och sessions förfallodatum är viktiga för att hantera långsamma och offlineprenumeranter och säkerställa effektiv minnesanvändning.

Relaterat innehåll