Opracowywanie aplikacji o wysokiej dostępności za pomocą brokera MQTT
Tworzenie aplikacji o wysokiej dostępności przy użyciu brokera MQTT wymaga starannego rozważenia typów sesji, jakości usług (QoS), potwierdzenia komunikatów, równoległego przetwarzania komunikatów, przechowywania komunikatów i subskrypcji udostępnionych. Broker MQTT oferuje rozproszony broker komunikatów w pamięci i magazyn, który zapewnia przechowywanie komunikatów i wbudowane zarządzanie stanem za pomocą semantyki MQTT.
W poniższych sekcjach opisano ustawienia i funkcje, które przyczyniają się do niezawodnej, zerowej utraty komunikatów i aplikacji rozproszonej.
Jakość usług (QoS)
Zarówno wydawcy, jak i subskrybenci powinni używać QoS-1 do zagwarantowania dostarczania komunikatów co najmniej raz. Broker MQTT przechowuje i ponownie przesyła komunikaty, dopóki nie otrzyma potwierdzenia (ACK) od adresata, upewniając się, że żadne komunikaty nie zostaną utracone podczas transmisji.
Typ sesji i flaga Clean-Session
Aby zapewnić zero utraty komunikatów, ustaw flagę clean-start na false podczas nawiązywania połączenia z brokerem MQTT. To ustawienie informuje brokera o zachowaniu stanu sesji klienta, zachowaniu subskrypcji i niezaznaczonych komunikatach między połączeniami. Jeśli klient rozłącza się i ponownie nawiąż połączenie, wznawia od miejsca, w którym został przerwany, odbierając wszelkie niezaznaczone komunikaty QoS-1 za pośrednictwem ponawiania próby dostarczania komunikatów. Jeśli skonfigurowano, broker MQTT wygaśnie sesję klienta, jeśli klient nie połączy się ponownie w interwale wygaśnięcia sesji Wartość domyślna to jeden dzień.
Receive-Max w aplikacjach wielowątkowych
Wielowątkowe aplikacje powinny używać funkcji receive-max (65 535 max), aby przetwarzać komunikaty równolegle i stosować sterowanie przepływem. To ustawienie optymalizuje przetwarzanie komunikatów, umożliwiając jednoczesne działanie wielu wątków na komunikatach i bez przeciążenia aplikacji przez brokera z wysoką szybkością komunikatów powyżej pojemności aplikacji. Każdy wątek może przetworzyć komunikat niezależnie i wysłać potwierdzenie po zakończeniu. Typowym rozwiązaniem jest skonfigurowanie maksymalnej liczby wątków używanych przez aplikację proporcjonalnie do liczby wątków.
Potwierdzanie wiadomości
Gdy aplikacja subskrybenta wysyła potwierdzenie dla komunikatu QoS-1, przejmuje własność wiadomości. Po otrzymaniu potwierdzenia dla komunikatu QoS-1 broker MQTT przestaje śledzić komunikat dla tej aplikacji i tematu. Prawidłowe przeniesienie własności zapewnia zachowanie komunikatów w przypadku problemów z przetwarzaniem lub awarii aplikacji. Jeśli aplikacja chce chronić ją przed awariami aplikacji, aplikacja nie powinna przejąć własności przed pomyślnym ukończeniem przetwarzania tego komunikatu. Aplikacje subskrybujące brokera MQTT powinny opóźniać potwierdzanie komunikatów, dopóki przetwarzanie nie zostanie ukończone w celu otrzymania maksymalnej wartości z maksymalnie 65 535. Może to obejmować przekazywanie komunikatu lub pochodnego komunikatu do brokera MQTT w celu dalszego wysyłania.
Zachowanie przechowywania komunikatów i brokera
Broker zachowuje komunikaty, dopóki nie otrzyma potwierdzenia od subskrybenta, zapewniając zerową utratę komunikatów. To zachowanie gwarantuje, że nawet jeśli aplikacja subskrybenta ulegnie awarii lub tymczasowo utraci łączność, komunikaty nie zostaną utracone i mogą być przetwarzane po ponownym połączeniu aplikacji. Komunikaty brokera MQTT mogą wygasnąć, jeśli zostały skonfigurowane przez interwał wygaśnięcia komunikatu, a subskrybent nie używa komunikatu.
Zachowane komunikaty
Zachowane komunikaty zachowują stan aplikacji tymczasowej, takie jak najnowszy stan lub wartość dla określonego tematu. Gdy nowy klient subskrybuje temat, otrzymuje ostatni zachowany komunikat, zapewniając, że ma najbardziej aktualne informacje.
Keep-Alive
Aby zapewnić wysoką dostępność w przypadku błędów lub pomyłek połączenia, ustaw odpowiednie interwały utrzymania aktywności dla komunikacji klient-serwer. W okresach bezczynności klienci wysyłają żądania PINGREQs, oczekując na pinGRESPs. Jeśli nie ma odpowiedzi, zaimplementuj logikę automatycznego ponownego łączenia w kliencie, aby ponownie nawiązać połączenia. Większość klientów, takich jak Paho , ma wbudowaną logikę ponawiania prób. Ponieważ broker MQTT jest odporny na błędy, ponowne nawiązywanie połączenia powiedzie się, jeśli istnieje co najmniej dwa wystąpienia brokera w dobrej kondycji, fronton i zaplecze.
Spójność ostateczna z subskrypcją QoS-1
Subskrypcje MQTT z funkcją QoS-1 zapewniają spójność ostateczną w identycznych wystąpieniach aplikacji, subskrybując udostępniony temat. W miarę publikowania komunikatów wystąpienia odbierają i replikują dane z co najmniej jednokrotnym dostarczaniem. Wystąpienia muszą obsługiwać duplikaty i tolerować tymczasowe niespójności, dopóki dane nie zostaną zsynchronizowane.
Subskrypcje udostępnione
Subskrypcje udostępnione umożliwiają równoważenie obciążenia w wielu wystąpieniach aplikacji o wysokiej dostępności. Zamiast każdego subskrybenta odbierającego kopię każdego komunikatu, komunikaty są dystrybuowane równomiernie wśród subskrybentów. Broker MQTT obsługuje obecnie tylko algorytm działania okrężnego w celu dystrybucji komunikatów, co umożliwia aplikacji skalowanie w poziomie. Typowym przypadkiem użycia jest wdrożenie wielu zasobników przy użyciu zestawu replik Platformy Kubernetes, które wszystkie subskrybują brokera MQTT przy użyciu tego samego filtru tematu w subskrypcji udostępnionej.
Magazyn stanów
Magazyn stanów to replikowana w pamięci funkcja HashMap do zarządzania stanem przetwarzania aplikacji. W przeciwieństwie do etcd, na przykład magazyn stanów określa priorytet przepływności o wysokiej szybkości, skalowanie w poziomie i małe opóźnienia za pośrednictwem struktur danych w pamięci, partycjonowania i replikacji łańcuchowej. Umożliwia ona aplikacjom używanie magazynu stanów rozproszonego charakteru i odporności na uszkodzenia przy jednoczesnym szybkim uzyskiwaniu dostępu do spójnego stanu w wystąpieniach. Aby użyć wbudowanego magazynu klucz-wartość udostępnianego przez brokera rozproszonego:
Zaimplementuj operacje magazynu efemerycznego i pobierania przy użyciu interfejsu API magazynu klucz-wartość brokera, zapewniając właściwą obsługę błędów i spójność danych. Stan efemeryczny to krótkotrwały magazyn danych używany w przetwarzaniu stanowym w celu szybkiego dostępu do wyników pośrednich lub metadanych podczas obliczeń w czasie rzeczywistym. W kontekście aplikacji wysokiej dostępności stan efemeryczny pomaga odzyskać stany aplikacji między awariami. Można go zapisać na dysku, ale pozostaje tymczasowy, w przeciwieństwie do magazynu zimnego, który jest przeznaczony do długoterminowego przechowywania rzadko używanych danych.
Użyj magazynu stanów do udostępniania stanu, buforowania, konfiguracji lub innych podstawowych danych między wieloma wystąpieniami aplikacji, co pozwala zachować spójny widok danych.
Korzystanie z wbudowanej integracji języka Dapr brokera MQTT
W przypadku prostszych przypadków użycia aplikacja może korzystać z języka Dapr (rozproszonego środowiska uruchomieniowego aplikacji). Dapr to przenośne, przenośne środowisko uruchomieniowe oparte na zdarzeniach, które upraszcza tworzenie mikrousług i aplikacji rozproszonych. Oferuje zestaw bloków konstrukcyjnych, takich jak wywołanie między usługami, zarządzanie stanem i publikowanie/subskrybowanie komunikatów.
Język Dapr jest oferowany jako część brokera MQTT, abstrakcji szczegółów zarządzania sesjami MQTT, QoS komunikatów i potwierdzenia oraz wbudowanych magazynów klucz-wartość, dzięki czemu jest to praktyczny wybór do tworzenia aplikacji o wysokiej dostępności dla prostych przypadków użycia przez:
Zaprojektuj aplikację przy użyciu bloków konstrukcyjnych języka Dapr, takich jak zarządzanie stanem do obsługi magazynu klucz-wartość, i opublikuj/subskrybuj komunikaty na potrzeby interakcji z brokerem MQTT. Jeśli przypadek użycia wymaga bloków konstrukcyjnych i abstrakcji, które nie są obsługiwane przez język Dapr, rozważ użycie wcześniej wymienionych funkcji brokera MQTT.
Zaimplementuj aplikację przy użyciu preferowanego języka programowania i platformy, korzystając z zestawów SDK lub interfejsów API języka Dapr w celu bezproblemowej integracji z brokerem i magazynem par klucz-wartość.
Lista kontrolna tworzenia aplikacji o wysokiej dostępności
- Wybierz odpowiednią bibliotekę klienta MQTT dla języka programowania. Klient powinien obsługiwać protokół MQTT v5. Użyj biblioteki opartej na języku C lub Rust, jeśli aplikacja jest wrażliwa na opóźnienia.
- Skonfiguruj bibliotekę klienta, aby nawiązać połączenie z brokerem MQTT z ustawioną
falseflagą clean-session i żądanym poziomem QoS (QoS-1). - Określ odpowiednią wartość dla wygasania sesji, wygaśnięcia komunikatu i interwałów utrzymania aktywności.
- Zaimplementuj logikę przetwarzania komunikatów dla aplikacji subskrybenta, w tym wysyłanie potwierdzenia, gdy komunikat został pomyślnie dostarczony lub przetworzony.
- W przypadku aplikacji wielowątowych skonfiguruj parametr max-receive , aby umożliwić równoległe przetwarzanie komunikatów.
- Korzystaj z zachowanych komunikatów w celu zachowania stanu aplikacji tymczasowej.
- Skorzystaj z rozproszonego magazynu stanów, aby zarządzać stanem efemerycznej aplikacji.
- Oceń dapr, aby opracować aplikację, jeśli przypadek użycia jest prosty i nie wymaga szczegółowej kontroli nad połączeniem MQTT ani obsługą komunikatów.
- Zaimplementuj udostępnione subskrypcje, aby równomiernie dystrybuować komunikaty między wieloma wystąpieniami aplikacji, co pozwala na efektywne skalowanie.