Edge-program med hög tillgänglighet för Azure IoT Operations

När du skapar ett program med hög tillgänglighet med hjälp av MQTT-asynkronisering måste du noga överväga sessionstyper, tjänstkvalitet (QoS), meddelandebekräftelser, parallell meddelandebearbetning, kvarhållning av meddelanden och delade prenumerationer. MQTT Broker har en distribuerad, minnesintern meddelandekö och lagring som ger kvarhållning av meddelanden och inbyggd tillståndshantering med MQTT-semantik.

I följande avsnitt beskrivs de inställningar och funktioner som bidrar till en robust, noll meddelandeförlust och distribuerat program.

Tjänstkvalitet (QoS)

Både utgivare och prenumeranter bör använda QoS-1 för att garantera meddelandeleverans minst en gång. MQTT-koordinatorn lagrar och återger meddelanden tills den tar emot en bekräftelse (ACK) från mottagaren, vilket säkerställer att inga meddelanden går förlorade under överföringen.

Sessionstyp och flagga för ren session

För att säkerställa noll meddelandeförlust anger du flaggan clean-start till false när du ansluter till MQTT-asynkron meddelandekö. Den här inställningen informerar koordinatorn om att behålla sessionstillståndet för klienten, vilket bevarar prenumerationer och obemärkta meddelanden mellan anslutningar. Om klienten kopplar från och senare återansluter återupptas den där den slutade och tar emot eventuella obemärkta QoS-1-meddelanden via återförsök av meddelandeleverans. Om den konfigureras upphör MQTT-asynkron meddelandekö att gälla om klienten inte återansluter inom sessionsförfallointervallet Standardvärdet är en dag.

Ta emot max i flertrådade program

Flertrådade program bör använda maximalt antal ( max 65 535) för att bearbeta meddelanden parallellt och tillämpa flödeskontroll. Den här inställningen optimerar meddelandebearbetningen genom att tillåta att flera trådar fungerar på meddelanden samtidigt och utan att asynkron meddelandekö överbelastar programmet med en hög meddelandefrekvens över programkapaciteten. Varje tråd kan bearbeta ett meddelande oberoende av varandra och skicka bekräftelsen när den är klar. En vanlig metod är att konfigurera max-receive proportionellt till antalet trådar som programmet använder.

Bekräfta meddelanden

När ett prenumerantprogram skickar en bekräftelse för ett QoS-1-meddelande tar det över ägarskapet för meddelandet. När MQTT-koordinatorn får bekräftelse för ett QoS-1-meddelande slutar han spåra meddelandet för programmet och ämnet. Korrekt överföring av ägarskap säkerställer bevarande av meddelanden vid bearbetningsproblem eller programkrascher. Om ett program vill skydda det från programkrascher bör programmet inte ta över ägarskapet innan bearbetningen av meddelandet slutförs. Program som prenumererar på MQTT-asynkron meddelandekö bör fördröja bekräftelse av meddelanden tills bearbetningen har slutförts till maxvärdet för mottagning med högst 65 535. Detta kan omfatta vidarebefordran av meddelandet, eller ett derivat av meddelandet, till MQTT-koordinatorn för vidare sändning.

Beteende för kvarhållning av meddelanden och koordinatorer

Asynkron meddelandekö behåller meddelanden tills den tar emot en bekräftelse från en prenumerant, vilket säkerställer noll meddelandeförlust. Det här beteendet garanterar att även om ett prenumerantprogram tillfälligt kraschar eller förlorar anslutningen går meddelanden inte förlorade och kan bearbetas när programmet återansluts. MQTT-asynkrona meddelanden kan upphöra att gälla om de konfigureras med meddelandeförfallointervallet och en prenumerant inte använde meddelandet.

Behållna meddelanden

Behållna meddelanden upprätthåller tillfälligt programtillstånd, till exempel den senaste statusen eller värdet för ett visst ämne. När en ny klient prenumererar på ett ämne får den det senast behållna meddelandet, vilket säkerställer att det har den senaste informationen.

Keep-Alive

För att säkerställa hög tillgänglighet vid anslutningsfel eller droppar anger du lämpliga keep-alive-intervall för klient-server-kommunikation. Under inaktiva perioder skickar klienter PINGREQs i väntan på PINGRESP:er. Om inget svar finns implementerar du logik för automatisk återanslutning i klienten för att återupprätta anslutningar. De flesta klienter som Paho har inbyggd logik för återförsök. Eftersom MQTT-koordinatorn är feltolerant lyckas en återanslutning om det finns minst två felfria broker-instanser en klientdel och en serverdel.

Slutlig konsekvens med QoS-1-prenumeration

MQTT-prenumerationer med QoS-1 säkerställer slutlig konsekvens mellan identiska programinstanser genom att prenumerera på ett delat ämne. När meddelanden publiceras tar instanser emot och replikerar data med leverans minst en gång. Instanserna måste hantera dubbletter och tolerera tillfälliga inkonsekvenser tills data synkroniseras.

Delade prenumerationer

Delade prenumerationer möjliggör belastningsutjämning över flera instanser av ett program med hög tillgänglighet. I stället för att varje prenumerant får en kopia av varje meddelande distribueras meddelandena jämnt mellan prenumeranterna. MQTT Broker stöder för närvarande endast en resursallokeringsalgoritm för att distribuera meddelanden som gör att ett program kan skalas ut. Ett vanligt användningsfall är att distribuera flera poddar med Kubernetes ReplicaSet som alla prenumererar på MQTT Broker med samma ämnesfilter i en delad prenumeration.

Tillståndslager

Tillståndsarkivet är en replikerad minnesintern HashMap för hantering av programbearbetningstillstånd. Till skillnad från etcd prioriterar till exempel tillståndslager dataflöde med hög hastighet, horisontell skalning och låg svarstid genom minnesintern datastrukturer, partitionering och kedjereplikering. Det gör att program kan använda tillståndet lagrar distribuerad natur och feltolerans samtidigt som ett konsekvent tillstånd snabbt nås mellan instanser. För att använda den inbyggda nyckelvärdelagringen som tillhandahålls av den distribuerade mäklaren:

• Implementera tillfälliga lagrings- och hämtningsåtgärder med hjälp av api:et för nyckel/värde-lagring för att säkerställa korrekt felhantering och datakonsekvens. Tillfälliga tillstånd är en kortlivad datalagring som används i tillståndskänslig bearbetning för snabb åtkomst till mellanliggande resultat eller metadata under realtidsberäkningar. I samband med HA-programmet hjälper ett tillfälliga tillstånd till att återställa programtillstånd mellan krascher. Det kan skrivas till disken men är fortfarande tillfälligt, till skillnad från kall lagring som är utformad för långsiktig lagring av data som används sällan.

• Använd tillståndslagret för delningstillstånd, cachelagring, konfiguration eller andra viktiga data mellan flera instanser av programmet, så att de kan ha en konsekvent vy över data.

Checklista för att utveckla ett program med hög tillgänglighet

• Välj ett lämpligt MQTT-klientbibliotek för ditt programmeringsspråk. Klienten bör ha stöd för MQTT v5. Använd ett C- eller Rust-baserat bibliotek om ditt program är känsligt för svarstid.
• Konfigurera klientbiblioteket för att ansluta till MQTT-koordinatorn med flaggan clean-session inställd på false och önskad QoS-nivå (QoS-1).
• Bestäm ett lämpligt värde för sessionsförfallodatum, meddelandeförfallodatum och keep-alive-intervall.
• Implementera logiken för meddelandebearbetning för prenumerantprogrammet, inklusive att skicka en bekräftelse när meddelandet har levererats eller bearbetats.
• För flertrådade program konfigurerar du parametern max-receive för att aktivera parallell meddelandebearbetning.
• Använd bevarade meddelanden för att behålla tillfälligt programtillstånd.
• Använd det distribuerade tillståndsarkivet för att hantera tillfälliga programtillstånd.
• Implementera delade prenumerationer för att fördela meddelanden jämnt mellan flera instanser av programmet, vilket möjliggör effektiv skalning.

Relaterat innehåll

• Data-persistens i MQTT-brokerns tillståndslager