Delen via

Maximaal beschikbare toepassingen ontwikkelen met MQTT-broker

  • Artikel

Het maken van een maximaal beschikbare toepassing met behulp van MQTT Broker omvat zorgvuldige overweging van sessietypen, QoS (Quality of Service), berichtbevestigingen, parallelle berichtverwerking, berichtretentie en gedeelde abonnementen. MQTT-broker beschikt over een gedistribueerde berichtenbroker en -opslag in het geheugen die berichtenretentie en ingebouwd statusbeheer biedt met MQTT-semantiek.

In de volgende secties worden de instellingen en functies uitgelegd die bijdragen aan een robuuste, nul berichtverlies en gedistribueerde toepassing.

Quality of service (QoS)

Zowel uitgevers als abonnees moeten QoS-1 gebruiken om de bezorging van berichten ten minste één keer te garanderen. De MQTT-broker slaat berichten op en verzendt deze opnieuw totdat deze een bevestiging (ACK) van de ontvanger ontvangt, zodat er geen berichten verloren gaan tijdens de verzending.

Sessietype en vlag Sessie opschonen

Als u wilt voorkomen dat er geen berichten verloren gaan, stelt u de vlag clean-start in op false wanneer u verbinding maakt met de MQTT-broker. Deze instelling informeert de broker om de sessiestatus voor de client te behouden, abonnementen te behouden en niet-bekende berichten tussen verbindingen te behouden. Als de verbinding met de client wordt verbroken en later opnieuw wordt verbonden, wordt de verbinding hervat vanaf waar de client was gebleven en ontvangt u eventuele niet-bekende QoS-1-berichten via nieuwe poging tot bezorging van berichten. Indien geconfigureerd, verloopt MQTT-broker de clientsessie als de client niet opnieuw verbinding maakt binnen het interval voor het verlopen van de sessie. De standaardwaarde is één dag.

Receive-Max in multithreaded toepassingen

Multithreaded-toepassingen moeten gebruikmaken van receive-max (maximaal 65.535) om berichten parallel te verwerken en stroombeheer toe te passen. Deze instelling optimaliseert de verwerking van berichten doordat meerdere threads gelijktijdig aan berichten kunnen werken en zonder de broker de toepassing te overbelasten met een hoge berichtsnelheid boven de capaciteit van de toepassing. Elke thread kan een bericht onafhankelijk verwerken en de bevestiging verzenden na voltooiing. Een typische procedure is het configureren van max-receive proportioneel aan het aantal threads dat door de toepassing wordt gebruikt.

Berichten bevestigen

Wanneer een abonneetoepassing een bevestiging voor een QoS-1-bericht verzendt, wordt het eigendom van het bericht. Na ontvangst van bevestiging voor een QoS-1-bericht stopt de MQTT-broker met het bijhouden van het bericht voor die toepassing en dat onderwerp. De juiste overdracht van het eigendom zorgt voor het behoud van berichten in het geval van verwerkingsproblemen of vastlopen van toepassingen. Als een toepassing deze wil beveiligen tegen vastlopen van toepassingen, moet de toepassing geen eigenaar worden voordat de verwerking van dat bericht is voltooid. Toepassingen die zich abonneren op MQTT-broker, moeten het bevestigen van berichten vertragen totdat de verwerking is voltooid tot maximaal 65.535. Dit kan omvatten het doorgeven van het bericht, of een afgeleide van het bericht, aan de MQTT-broker voor verdere verzending.

Gedrag van berichtretentie en broker

De broker bewaart berichten totdat deze een bevestiging ontvangt van een abonnee, waardoor er geen bericht verloren gaat. Dit gedrag garandeert dat zelfs als een abonneetoepassing de verbinding tijdelijk vastloopt of verliest, berichten niet verloren gaan en kunnen worden verwerkt zodra de toepassing opnieuw verbinding maakt. MQTT-brokerberichten kunnen verlopen als deze zijn geconfigureerd door het interval voor het verlopen van berichten en een abonnee het bericht niet heeft gebruikt.

Bewaarde berichten

Bewaarde berichten behouden de status van de tijdelijke toepassing, zoals de meest recente status of waarde voor een specifiek onderwerp. Wanneer een nieuwe client zich abonneert op een onderwerp, ontvangt deze het laatst bewaarde bericht, zodat het over de meest recente informatie beschikt.

Keep-Alive

Als u hoge beschikbaarheid wilt garanderen in geval van verbindingsfouten of -dalingen, stelt u geschikte keep-alive-intervallen in voor client-servercommunicatie. Tijdens niet-actieve perioden verzenden clients PINGREQs, wachtend op PINGRESPs. Als er geen antwoord is, implementeert u logica voor automatisch opnieuw verbinden in de client om verbindingen opnieuw tot stand te brengen. De meeste clients zoals Paho hebben logica voor opnieuw proberen ingebouwd. Omdat MQTT-broker fouttolerant is, slaagt een herverbinding als er ten minste twee gezonde brokerexemplaren een front-end en een back-end zijn.

Uiteindelijke consistentie met QoS-1-abonnement

MQTT-abonnementen met QoS-1 zorgen voor uiteindelijke consistentie tussen identieke toepassingsexemplaren door zich te abonneren op een gedeeld onderwerp. Wanneer berichten worden gepubliceerd, ontvangen en repliceren instanties gegevens met ten minste één levering. De exemplaren moeten duplicaten verwerken en tijdelijke inconsistenties tolereren totdat gegevens worden gesynchroniseerd.

Gedeelde abonnementen

Gedeelde abonnementen maken taakverdeling mogelijk voor meerdere exemplaren van een maximaal beschikbare toepassing. In plaats van elke abonnee die een kopie van elk bericht ontvangt, worden de berichten gelijkmatig verdeeld over de abonnees. MQTT Broker ondersteunt momenteel alleen een round robin-algoritme om berichten te distribueren, zodat een toepassing kan worden uitgeschaald. Een typische use case is het implementeren van meerdere pods met behulp van Kubernetes ReplicaSet die allemaal zijn geabonneerd op MQTT Broker met behulp van hetzelfde onderwerpfilter in een gedeeld abonnement.

Statusarchief

Statusarchief is een gerepliceerde hashmap in het geheugen voor het beheren van de verwerkingsstatus van toepassingen. In tegenstelling tot etcd geeft de statusopslag bijvoorbeeld prioriteit aan hoge doorvoersnelheid, horizontaal schalen en lage latentie via gegevensstructuren in het geheugen, partitionering en ketenreplicatie. Hiermee kunnen toepassingen gedistribueerde aard en fouttolerantie gebruiken met behulp van de statusopslag, terwijl ze snel toegang hebben tot een consistente status in verschillende exemplaren. Het ingebouwde sleutel-waardearchief van de gedistribueerde broker gebruiken:

  • Implementeer tijdelijke opslag- en ophaalbewerkingen met behulp van de sleutel-waardeopslag-API van de broker, waardoor de juiste foutafhandeling en gegevensconsistentie worden gegarandeerd. Kortstondige status is een kortdurende gegevensopslag die wordt gebruikt in stateful verwerking voor snelle toegang tot tussenliggende resultaten of metagegevens tijdens realtime berekeningen. In de context van een HA-toepassing helpt een kortstondige status toepassingsstatussen te herstellen tussen crashes. Het kan naar de schijf worden geschreven, maar blijft tijdelijk, in tegenstelling tot koude opslag die is ontworpen voor langetermijnopslag van niet-frequent geopende gegevens.

  • Gebruik het statusarchief voor het delen van de status, caching, configuratie of andere essentiële gegevens tussen meerdere exemplaren van de toepassing, zodat ze een consistente weergave van de gegevens kunnen houden.

De ingebouwde Dapr-integratie van MQTT Broker gebruiken

Voor eenvoudigere gebruiksscenario's kan een toepassing Dapr (Gedistribueerde Application Runtime) gebruiken. Dapr is een opensource, draagbare, gebeurtenisgestuurde runtime die het bouwen van microservices en gedistribueerde toepassingen vereenvoudigt. Het biedt een reeks bouwstenen, zoals service-naar-service-aanroep, statusbeheer en berichten publiceren/abonneren.

Dapr wordt aangeboden als onderdeel van MQTT-broker, waarbij details van MQTT-sessiebeheer, QoS van berichten en bevestiging en ingebouwde sleutel-waardearchieven worden geabstraheerd, waardoor het een praktische keuze is voor het ontwikkelen van een maximaal beschikbare toepassing voor eenvoudige gebruiksvoorbeelden door:

  • Ontwerp uw toepassing met behulp van de bouwstenen van Dapr, zoals statusbeheer voor het verwerken van het sleutel-waardearchief, en publiceer/abonneer berichten voor interactie met de MQTT-broker. Als voor de use-case bouwstenen en abstracties zijn vereist die niet worden ondersteund door Dapr, kunt u overwegen de eerder genoemde MQTT-brokerfuncties te gebruiken.

  • Implementeer de toepassing met behulp van uw favoriete programmeertaal en framework, waarbij gebruik wordt gemaakt van Dapr SDK's of API's voor naadloze integratie met de broker en het sleutel-waardearchief.

Controlelijst voor het ontwikkelen van een maximaal beschikbare toepassing

  • Kies een geschikte MQTT-clientbibliotheek voor uw programmeertaal. De client moet MQTT v5 ondersteunen. Gebruik een C- of Rust-bibliotheek als uw toepassing gevoelig is voor latentie.
  • Configureer de clientbibliotheek om verbinding te maken met MQTT-broker met de vlag Clean Session ingesteld op false en het gewenste QoS-niveau (QoS-1).
  • Beslis een geschikte waarde voor het verlopen van sessies, het verlopen van berichten en keep-alive-intervallen.
  • Implementeer de berichtverwerkingslogica voor de abonneetoepassing, inclusief het verzenden van een bevestiging wanneer het bericht is bezorgd of verwerkt.
  • Voor multithreaded-toepassingen configureert u de parameter max-receive om parallelle berichtverwerking in te schakelen.
  • Gebruik bewaarde berichten voor het behouden van de status van de toepassing.
  • Gebruik het gedistribueerde statusarchief om de tijdelijke toepassingsstatus te beheren.
  • Evalueer Dapr om uw toepassing te ontwikkelen als uw use-case eenvoudig is en geen gedetailleerde controle over de MQTT-verbinding of berichtafhandeling vereist.
  • Implementeer gedeelde abonnementen om berichten gelijkmatig te verdelen over meerdere exemplaren van de toepassing, zodat u efficiënt kunt schalen.

Gerelateerde inhoud