Delen via

Broker MQTT-clientopties configureren

  • Artikel

Belangrijk

Voor deze instelling moet u de Broker-resource wijzigen. Deze wordt alleen geconfigureerd bij de eerste implementatie met behulp van de Azure CLI of Azure Portal. Er is een nieuwe implementatie vereist als brokerconfiguratiewijzigingen nodig zijn. Zie Standaardbroker aanpassen voor meer informatie.

De geavanceerde clientopties van MQTT Broker bepalen hoe de broker communiceert met MQTT-clients. Deze instellingen, onderhandeld tussen de broker en de client tijdens de verbinding, omvatten het verlopen van sessies, het verlopen van berichten, het ontvangen van het maximum en het actief houden. De enige instelling die specifiek is voor Azure IoT-bewerkingen, is de limiet voor de wachtrij voor abonnees.

Zie de naslaginformatie over de ClientConfig-API voor de volledige lijst met beschikbare instellingen.

In veel scenario's zijn de standaardclientinstellingen voldoende. Als u de standaardclientinstellingen voor de MQTT-broker wilt overschrijven, bewerkt u de advanced.clients sectie in de Broker-resource. Op dit moment wordt deze onderdrukking alleen ondersteund door de --broker-config-file vlag te gebruiken wanneer u IoT-bewerkingen implementeert met behulp van de az iot ops create opdracht.

Om aan de slag te gaan, bereidt u een Broker-configuratiebestand voor in JSON-indeling, zoals in het volgende voorbeeld:

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

Implementeer vervolgens IoT-bewerkingen met behulp van de az iot ops create opdracht met de --broker-config-file vlag, zoals de volgende opdracht. (Andere parameters worden weggelaten voor beknoptheid.)

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

Zie De Ondersteuning van Azure CLI voor geavanceerde MQTT Broker-configuratie en Broker-voorbeelden voor meer informatie.

Wachtrijlimiet voor abonnees

De MQTT-broker houdt een wachtrij bij voor elke abonnee met QoS 1-berichten die wachten om te worden bezorgd. Berichten worden toegevoegd aan deze wachtrij wanneer ze van de uitgever worden ontvangen. Ze worden verwijderd nadat ze zijn bezorgd en bevestigd door de abonnee met een PUBACK-bericht. Als berichten sneller binnenkomen dan de abonnee deze kan bevestigen of als de abonnee offline is met een permanente sessie, kan de wachtrij groot worden.

De MQTT-broker kan deze berichten bufferen op schijf om geheugen te besparen, maar deze tactiek is mogelijk niet altijd voldoende. De schijfbuffer is mogelijk niet ingesteld of deze kan vol zijn vanwege andere abonnees. Daarom helpt de wachtrijlimiet voor abonnees ervoor te zorgen dat de broker te veel geheugen voor één abonnee gebruikt.

De wachtrijlimiet voor abonnees heeft twee instellingen:

  • Lengte: Het maximum aantal berichten dat in de wachtrij kan worden geplaatst voor één abonnee. Als de wachtrij vol is en er een nieuw bericht binnenkomt, laat de broker het bericht vallen op basis van de geconfigureerde strategie.

  • Strategie: de strategie die moet worden gebruikt wanneer de wachtrij vol is. De twee strategieën zijn:

    • Geen: berichten worden niet verwijderd , tenzij de sessie verloopt en de wachtrij voor onbepaalde tijd kan groeien. Dit gedrag is de standaardinstelling.
    • DropOldest: Het oudste bericht in de wachtrij wordt verwijderd.

De limiet geldt alleen voor de uitgaande wachtrij van de abonnee, die berichten bevat die geen pakket-id's hebben gekregen, omdat de wachtrij in de vlucht vol is. Deze limiet geldt niet voor de in-flight wachtrij.

Omdat de limiet per back-endpartitie wordt toegepast, kan de MQTT-broker het totale aantal uitgaande berichten voor een abonnee in het hele cluster niet garanderen. Als u bijvoorbeeld de lengte instelt op 10.000, betekent dit niet dat de abonnee maximaal 10.000 berichten ontvangt. In plaats daarvan kan het maximaal berichten 10,000 * number of partitions * number of backend workers ontvangen.

Trage abonnees

Een trage abonnee is een abonnee die niet kan bijhouden met de snelheid van binnenkomende berichten. Dit probleem kan optreden als de abonnee berichten langzaam verwerkt, is verbroken of offline is. De wachtrijlimiet voor abonnees helpt voorkomen dat een trage abonnee te veel geheugen verbruikt.

Verlopen van bericht

De maxMessageExpirySeconds instelling bepaalt hoe lang een bericht in de wachtrij kan blijven voordat het verloopt. Als een bericht langer in de wachtrij blijft dan de maximale verlooptijd, wordt het gemarkeerd als verlopen. Verlopen berichten worden echter alleen verwijderd wanneer ze het begin van de wachtrij bereiken. Dit passieve verloopmechanisme helpt het geheugengebruik te beheren door ervoor te zorgen dat oude berichten uiteindelijk worden verwijderd.

Verloop van sessie

De maxSessionExpirySeconds instelling werkt met de limiet voor de abonneewachtrij om ervoor te zorgen dat berichten niet voor onbepaalde tijd in de wachtrij worden bewaard. Als een sessie verloopt, worden alle berichten in de wachtrij voor die sessie verwijderd. Deze procedure helpt voorkomen dat offlineabonnees te veel geheugen gebruiken door uiteindelijk de hele wachtrij te wissen.

Zowel het verlopen van berichten als het verlopen van sessies is belangrijk voor het beheren van trage en offline abonnees en het garanderen van efficiënt geheugengebruik.

Gerelateerde inhoud