Redis Sentinel vs Cluster

Redis można zidentyfikować jako zdalny serwer słownikowy, który jest zaprojektowany głównie dla prędkości. Ponadto jest szeroko stosowany jako pamięć podręczna i baza danych NoSQL. Jako baza danych lub pamięć podręczna ważne jest zapewnienie wysokiego wskaźnika dostępu do danych, wysokiej dostępności, odchylania danych i skalowalności. Redis wprowadził rozwiązania Sentinel i Cluster w celu rozwiązania wymienionych aspektów.

Klaster Redis

Technologia klastra Redis, która została wprowadzona z wersji 3.0 umożliwia skalowanie poziome dla danego wdrożenia Redis. W przypadku klastrów Redis dane są podzielone na wiele węzłów klastrów, które zapewniają spójną i wiarygodną warstwę usług danych dla aplikacji.

Trzeba mieć co najmniej trzy węzły główne, aby klaster mógł poprawnie funkcjonować. Ponadto każdy węzeł główny powinien mieć co najmniej jeden węzeł niewolniczy. Ponadto klastry Redis umożliwiają do pewnego stopnia wysoką dostępność, promując węzeł niewolnika powiązany z nieudaną instancją główną w przypadku sprzętu/oprogramowania lub awarii sieci.

Każdy węzeł klastra komunikuje się z innymi węzłami przy użyciu kanału komunikacyjnego węzłowego opartego na protokole binarnym. Ponadto każdy węzeł jest otwarty na połączenia klienta, wykorzystując standardowy port TCP.

Poniżej znajduje się szkic na wysokim poziomie podstawowej konfiguracji klastra Redis:

Profesjonaliści:

• SHARDING DANY
  • Dane są udostępniane wśród wielu węzłów i można je dynamicznie dostosować.
  • Ponieważ nie ma centralnego centrum sterowania, dane są automatycznie podzielone na węzły.
• Skalowalność
  • Klaster może skalować do 1000 węzłów. Węzły można usunąć lub dodać dynamicznie.

• Automatyczne przełączanie awaryjne

• • Redis Cluster obsługuje architekturę mistrzów i umożliwia wbudowaną technikę przełączania awaryjnego.

Cons:

• Nie do końca bardzo dostępne
  • W przypadku poważnej awarii większość głównych węzłów może zejść na dół, co powoduje, że cała klaster spadnie.
• Duża liczba węzłów na pojedynczy klaster
  • MUSI mieć co najmniej trzy instancje główne i pojedynczy węzeł niewolników na mistrz, który kończy się sześcioma węzłami, aby skonfigurować odpowiednią klaster Redis.
• Brak gwarancji spójności danych
  • Replikacja główna klastra Redis jest przetwarzana asynchronicznie i może wpływać na spójność.
• Brak obsługi biblioteki klientów dla klastra Redis
  • Istnieje minimalna liczba bibliotek klientów, które obsługują implementacje klastra Redis.
• Replikacja pojedynczej warstwy
  • Architektura replikacji głównej klastra Redis pozwala tylko na jedną warstwę. Dana instancja niewolnika może powtórzyć tylko węzeł główny.
• Klaster Redis może stracić uznane pisze w niektórych scenariuszach

• Obsługa danych jest bardziej skomplikowana

• • Ze względu na odchylenie danych administriny klastra powinni zarządzać wieloma plikami RDB i AOF. Ponadto potrzebny jest dodatkowy wysiłek, aby agregować pliki trwałości z wielu węzłów, aby wykonać kopię zapasową.

Redis Sentinel

Redis Sentinel to podejście o wysokiej dostępności dla wdrożeń Redis, które działają jako osobny program w tle. Wprowadza wiele funkcji do wdrożeń Redis poprzez ciągłe sprawdzanie statusu węzła głównego i niewolnika, powiadamiając znaczące zmiany związane z monitorowanymi instancjami za pomocą interfejsu API, inicjowanie automatycznego procesu awaryjnego, gdy wystąpi awaria główna, i działając jako źródło dla źródła dla Urząd dla klientów, aby znaleźć aktualnie aktywny adres IP węzła głównego Redis.

Konfiguracja Redis Sentinel można wdrożyć przy użyciu co najmniej trzech węzłów Sentinel, które mogą uniknąć większości problemów w danym wdrożeniu Redis. Ponadto, w danej konfiguracji Sentinel, wartość kworum określa minimalną liczbę węzłów wartowniczy.

Ogólnie rzecz biorąc, Redis Sentinel jest głównie stosowany do obsługi wysokiej dostępności bazy danych Redis, w której działa lepiej niż w podejściu do klastrowania.

Poniżej znajduje się ilustracja na wysokim poziomie konfiguracji minimalnej Sentinel Redis:

Profesjonaliści:

• Minimalna liczba węzłów
  • Całkowicie działające wdrożenie Redis Sentinel można uformować z trzema węzłami.
• Wysoce dostępne
  • Rozmieszczenie Redis Sentinel może przetrwać krytycznych awarii węzłów bez żadnej interwencji człowieka.
  • Może funkcjonować, gdy przynajmniej pojedyncza instancja główna jest dostępna, nawet jeśli każdy niewolnik jest na dół.
• Ulepszona replikacja główna
  • W rozmieszczeniu Redis Sentinel kilku niewolników może powtórzyć daną instancję główną.
• Prostota i elastyczność

• Redis Sentinel jest bardzo łatwy w utrzymaniu i ma również elastyczne opcje konfiguracji.

Cons:

• Brak obsługi odłamków
  • Odłamanie danych nie jest możliwe. Dlatego dostępność na dużą skalę dostępność może spowodować degrada.
• Brak skalowalności
• Przestarzałe odczyty
  • Zwykle węzły niewolników służą odczyt w rozmieszczeniu Redis Sentinel. Z powodu replikacji asynchronicznej odczyty mogą nie być aktualne.
• Redis Sentinel powinien być obsługiwany przez bibliotekę klientów
• Węzeł niewolniczy nie działa jak węzeł kopii zapasowej

Redis Sentinel vs Cluster

Klaster Redis i Sentinel to dwa podejścia, w których każde rozwiązuje różne aspekty związane z wdrożeniem Redis. Aby podkreślić, podejście klastra Redis jest bardziej odpowiednie do skomplikowanych implementacji, które dotyczą masowych zestawów danych, w których zapewnia automatyczne odchylenie danych w celu lepszej wydajności odczytu/zapisu, automatycznego przełączania awaryjnego i replikacji z dużą dostępnością w pewnym stopniu. Ponadto węzły klastra Redis można skalować bez wysiłku.

Z drugiej strony, Redis Sentinel bardziej koncentruje się na mniejszych implementacjach z myślą o wysokiej dostępności.

Dostępność

Klaster Redis nie obsługuje w pełni wysokiej dostępności. Ponieważ jeśli większość mistrzów nie jest dostępna, klaster może zejść. W przeciwieństwie do podejścia klastra, Redis Sentinel oferuje wysoką dostępność bez interwencji człowieka. Co najważniejsze, wartownik może przetrwać nawet z pojedynczą działającą instancją główną, gdy nastąpi krytyczna awaria.

SHARDING DANY

Klaster Redis oferuje możliwości odłamku, w których dane są rozmieszczone między wieloma węzłami, gdy klienci mają dostęp do sieci do wszystkich węzłów. Umożliwia zwiększoną wydajność i pojemność przechowywania danych.

Z drugiej strony Redis Sentinel nie oferuje możliwości odłamków. Ponieważ odłamek powoduje wykorzystanie braku równowagi mistrza i niewolnika.

Replikacja

Oba podejścia oferują replikację główną z pewnymi ograniczeniami. Redis Sentinel umożliwia replikację wielu warstw, w których kilka węzłów niewolników może replikować z danej instancji głównej. Natomiast podejście klastra Redis nie pozwala na replikację wielu warstw. Jest w stanie odtworzyć instancję główną do jednego węzła niewolnika. Oba podejścia zagrażają spójności z powodu replikacji asynchronicznej.

Skalowalność

Klastry Redis są wysoce skalowalne. Obsługuje do tysiąca węzłów w danej konfiguracji pojedynczej klastra. Ponadto klastry umożliwiają dynamiczne i bez wysiłku dodanie i usuwanie węzłów. Redis Sentinel nie jest skalowalny, a zapisy są skierowane do instancji głównej, dlatego wartownik nie jest w stanie poradzić.

Architektura

W pełni funkcjonalny Sentinel Redis można zbudować z zaledwie trzema węzłami. Ale aby skonfigurować klaster Redis, wymaga co najmniej trzech węzłów głównych i trzech dołączonych do nich trzech niewolników, co jest droższe niż w rozmieszczeniu Redis Sentinel.

Wniosek

Podsumowując, podejście klastra Redis bardziej koncentruje się na złożonych wdrożeniach, gdy ważna jest wysoka skalowalność, wysoka wydajność i wysoka przechowywanie danych, a wysoka dostępność nie jest znacząca. Z drugiej strony Redis Sentinel jest zbudowany przede wszystkim do prostych aplikacji, które koncentrują się głównie na wysokiej dostępności. W porównaniu, oba rozwiązania są dostarczane z ich zaletami i wadami, ale aby wspierać użytkowników końcowych z dokładniejszym wdrożeniem Redis.