Dela via

Konfigurera Asynkrona MQTT-klientalternativ

  • Artikel

Viktigt!

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

Asynkrona avancerade klientalternativ 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 ClientConfig API-referensen.

I många scenarier räcker standardklientinställningarna. Om du vill åsidosätta standardklientinställningarna för asynkron meddelandekö redigerar advanced.clients 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 Azure IoT Operations med hjälp av az iot ops create 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 Azure IoT Operations med kommandot az iot ops create 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 och tas bort när de har levererats och bekräftats av prenumeranten med en PUBACK. 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.

Asynkron meddelandekö kan buffras till disken för att spara minne, men det 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 är standardbeteendet.

    • 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 mäklaren 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. Detta kan inträffa 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 bara 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. Detta förhindrar 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.

Nästa steg