Klaster Redis Sentinel i Redis to dwa odrębne mechanizmy dostarczone przez Redis w celu zwiększenia niezawodności i dostępności, ale różnią się znacznie pod względem architektury, przypadków użycia i cech niezawodności.
Redis Sentinel to przede wszystkim rozwiązanie o wysokiej dostępności (HA) zaprojektowane dla konfiguracji Redis, które wykorzystują replikację, ale nie odsuwają danych. Sentinel monitoruje instancje Master i Replica Redis, zapewniając klientom automatyczne aktualizacje awaryjne i konfiguracyjne. Działa jako system rozproszony z wieloma instancjami Sentinel współpracującymi w celu niezawodnego wykrywania awarii. Jego podstawowe mocne strony niezawodności pochodzą z porozumienia zbiorowego (kworum) wśród wartowników w celu wykrycia awarii głównej i zainicjowania przełączania awaryjnego. Zmniejsza to fałszywe pozytywy i zapewnia, że działania awaryjne są autoryzowane przez większość, zachowując spójność systemu i dostępność. Sentinel obsługuje przełączanie awaryjne, promując najbardziej zaktualizowaną replikę do opanowania, rekonfigurując inne repliki i informując klientów o nowym adresie głównym. Projekt architektoniczny Sentinel pozwala uniknąć awaryjnego systemu awarii, wymagając wielu wystąpień na niezależnych maszynach lub strefach. Przeprowadza również ciągłe monitorowanie i zapewnia powiadomienia o stanie wystąpień Redis, zwiększając świadomość operacyjną i reakcję na problemy. Możliwości wysokiej dostępności Sentinel sprawiają, że nadaje się do mniejszych wdrożeń Redis, które wymagają przełączania awaryjnego i monitorowania, ale nie wymagają partycjonowania danych ani skalowania poziomego na dużą skalę.
Natomiast klaster Redis jest bardziej złożonym, zintegrowanym rozwiązaniem, które łączy odłamek danych z wysoką dostępnością. Partycje klastra automatycznie przesyła dane w wielu węzłach Redis (Masters), z których każdy potencjalnie ma repliki. Architektura klastrowania jest zdecentralizowana, bez jednego punktu zarządzania, co pozwala jej skalować poziomo i obsługiwać większe zestawy danych poprzez dystrybucję obciążenia między węzłami. Klaster Redis obejmuje wbudowaną replikację i automatyczne przełączenie awaryjne dla nieudanych węzłów, obsługując dalsze działanie podczas partycji sieciowych lub awarii węzłów. W przeciwieństwie do Sentinel, klaster Redis z natury zarządza dystrybucją danych (Sharding), który optymalizuje obciążenie pracą i równoważy wykorzystanie zasobów wśród Masters. Jednak klaster Redis ma pewne ograniczenia replikacji, takie jak replikacja jednowarstwowa (każda mistrz replikuje tylko swoich niewolników). Pomimo asynchronicznej replikacji w obu systemach, klaster jest przeznaczony do wyższej przepustowości i niższego opóźnienia na dużą skalę, dzięki odłamku i zrównoważonym obciążeniu.
Jeśli chodzi o wiarygodność, mechanizm przełączania awaryjnego Sentinel opiera się na wyroku i wyborze lidera Sentinel do wykonywania zadań związanych z przełączaniem awaryjnym, zapewniając staranną koordynację i zmniejszając szansę na podzielone scenariusze mózgu. Konfiguracje Sentinel zwykle obejmują co najmniej trzy instancje Sentinel w celu utrzymania systemu kworum odpornego na usterki, który może działać, nawet jeśli niektóre węzły Sentinel nie powiedzieli. Jednak Sentinel nie oferuje odchylania danych, co może prowadzić do niewykorzystania replik, ponieważ pisze tylko jeden mistrz. Ogranicza to zdolność do zwiększenia skali wielkości danych i obciążenia, co oznacza niezawodność pod względem dostępności danych, a prędkość dostępu może degradować w większych wdrożeniach.
Niezawodność Redis Cluster świeci podczas skalowania. Poprawia tolerancję błędów poprzez dystrybucję danych u wielu mistrzów i ich replikację. Klaster może kontynuować działalność, gdy niektóre węzły się nie powiedzie lub stają się nieosiągalne, pod warunkiem zachowania większości mistrzów. Rozproszony konsensus umożliwia automatyczne przełączanie awaryjne dla poszczególnych węzłów głównych i utrzymuje działanie klastra nawet podczas częściowych partycji sieciowych. To sprawia, że klaster Redis jest niezawodny w przypadku dużych, wysokich środowisk wymagających zarówno dostępności, jak i skalowalności poziomej. Jednak konfigurowanie, zarządzanie i odzyskiwanie po awarii w klastrze może być bardziej złożone, a niewłaściwe konfiguracje lub problemy sieciowe mogą prowadzić do niespójności podziału mózgu lub danych, jeśli kworum zostanie utracone lub procedury przełączania awaryjnego stanu Mishandle State.
Podsumowując, Redis Sentinel oferuje silną niezawodność koncentrującą się na wysokiej dostępności poprzez skoordynowane monitorowanie i przełączanie awaryjne w architekturze mistrzowskiej bez odchylenia. Obsługuje mniejsze wdrożenia lub scenariusze, w których wysoka dostępność jest krytyczna, ale objętość danych i obciążenie dostępu są możliwe do zarządzania przez jednego mistrza. Z drugiej strony klaster Redis zapewnia niezawodność w połączeniu ze skalowalności poziomej poprzez odchylenie danych i replikację w wielu węzłach, zapewniając bieżącą operację pomimo awarii węzłów i partycji sieciowych w większych, bardziej wymagających środowiskach. Wybór między nimi zależy od konkretnych potrzeb niezawodności w stosunku do wielkości danych, obciążenia pracą i złożonością, którą może tolerować system.
Ten przegląd zawiera szczegółowe rozważania dotyczące monitorowania, procesów przełączania awaryjnego, mechanizmów kworum, architektury replikacji, implikacji skalowalności i kompromisów operacyjnych dla niezawodności między Redis Sentinel a klastrem Redis.