Bazy danych Redis mogą przechowywać małe, krótkotrwałe i złożone obiekty, które utrzymują się przez miesiące. Niezależnie od złożoności i wielkości obiektów, ciągła dostępność tych danych jest koniecznością, aby zapewnić klientowi bezproblemową usługę zaplecza.Zwykle samodzielna instalacja Redis jest łatwa do skonfigurowania i wykorzystania. Ale nie jest to najlepsza opcja użycia w środowisku, w którym mogą wystąpić awarie węzłów. Trwałość danych można zachować za pomocą funkcji plików wyłącznie w dodatku Redis (AOF) w Redis, ale nie jest idealnym rozwiązaniem dla wysokiej dostępności. Podobnie pliki Redis RDB mogą być używane jako opcja kopii zapasowej, która jest reprezentacją danych w czasie w czasie. Obie te opcje nie dotyczą problemu nagłych awarii węzłów Redis.Tak więc Redis wprowadził kilka wbudowanych funkcji, aby obsługiwać wysoką dostępność baz danych Redis omówionych w następnej sekcji.

Replikacja bazy danych

Replikacja bazy danych jest podstawową techniką uczynienia tolerancji błędów w systemie bazy danych i dostępną w sposób ciągły. Replikacja kopiuje dane z podstawowej bazy danych (podstawowa baza danych) do jednej lub więcej baz danych niewolników (repliki), które zapewniają dostępne dane w dowolnym momencie, jeśli węzeł główny się nie powiedzie. Proces ten jest połączony z automatycznym procesem awaryjnym, który promuje nowy mistrz z dostępnych węzłów repliki, gdy węzeł główny się nie powiedzie.

Wbudowana replikacja Redis

Redis zaczął wspierać replikację z najwcześniejszych wersji i niezmiernie ulepszony. Wersja samodzielna obsługuje podstawową replikację za pomocą polecenia SlaveOF poprzez przekształcenie istniejącego węzła na niewolnika głównego węzła bazy danych. Ponadto funkcja Redis Sentinel umożliwia replikację z bardziej zaawansowaną funkcją przełączania awaryjnego. Ponadto klaster Redis obsługuje bogaty zestaw funkcji o wysokiej dostępności dla bardziej rozproszonych i dużych systemów baz danych.

Podstawowa replikacja redis za pomocą polecenia Slaveof

Jednym z podstawowych sposobów osiągnięcia replikacji Redis jest użycie polecenia Slaveof.

Jest o krok od uczynienia instancji Redis węzłem niewolniczym. Do pliku konfiguracji konkretnej instancji należy dodać następujący wiersz:

Slaveof

Przypadek użycia

Poniższy przykład pokazuje scenariusz, w którym dana instancja Redis jest skonfigurowana jako węzeł niewolnika węzła głównego, który działa w 127.0.0.1 adres w porcie 7000.

Dzięki tej konfiguracji główna baza danych skopiuje wszystkie dane do węzła niewolnika, który zapewnia niewolnik, jest dokładną kopią głównego węzła bazy danych.

Po uruchomieniu węzła głównego w 127.0.0.1 i Port 7000, uruchommy drugą instancję, której plik konfiguracyjny zawiera konfigurację Slaveof. Nowa instancja będzie działać w porcie 7001.

Nowa instancja jest uruchamiana pomyślnie i synchronizowana z głównymi biegami w 127.0.0.1 (port 7000).

Jeśli napiszesz dane do węzła głównego, można je odczytać z niewolnika w następujący sposób. Oznacza to, że Master i Replica zostały właściwie zsynchronizowane.

Pisanie danych do węzła głównego działa w porcie 7000 w następujący sposób.

Czytanie danych z węzła niewolnika działa w porcie 7001, jak pokazano następująco:

Z tą konfiguracją, gdy Redis Master nie powiedzie się, mamy już dokładną kopię podstawowej bazy danych działającej w porcie 7001. Podobnie możesz skonfigurować wielu niewolników dla danego węzła głównego. Jedyną wadą w tej konfiguracji jest to, że musisz ręcznie zająć się procesem przełączania awaryjnego.

Profesjonaliści

• Łatwe i mniej czasochłonne.
• Ta konfiguracja będzie działać tak długo, jak dostępny jest pojedynczy węzeł główny, a nawet bez jednego węzła niewolnika.
• Możliwe zautomatyzowanie z narzędziami do zarządzania konfiguracją.

Cons

• Główny proces awaryjnego nie jest zautomatyzowany.
• Ponieważ odczyty są asynchroniczne, mogą wystąpić nieustanne odczyty.
• Wykorzystanie mistrza i niewolników nie jest równe ze względu na odchylenie nie jest obsługiwane.

Wysoka dostępność z Redis Sentinel

Redis Sentinel został wprowadzony, aby poradzić sobie z wadami poprzedniego rozwiązania. Redis Sentinel to system rozproszony, który działa jako zaawansowane rozwiązanie o wysokiej dostępności dla Redis wraz z innymi funkcjami, takimi jak dostawca powiadomień, narzędzia monitorujące i dostawca konfiguracji dla klientów.

Sentinel jest w stanie automatycznie promować niewolnika do węzła głównego bez interwencji człowieka. Proces awaryjnego głównego rozpoczyna się, jeśli określona maksymalna liczba węzłów Sentinel (kworum) zgadza się, że węzeł główny nie jest dostępny. Tak więc dostępność węzłów Sentinel jest ważna. Zaleca się jednak użycie osobnego klastra Sentinel do uruchamiania węzłów Sentinel oddzielnie od węzłów głównych. Dzięki tej konfiguracji klienci Redis najpierw rozmawiają z węzłem Sentinel i proszą o informacje o aktualnie uruchomionym węźle głównym. Wtedy tylko klienci będą współpracować z obecnym mistrzem.

Możliwe jest uruchomienie serwera Redis w trybie Sentinel, jak pokazano w następującym poleceniu:

Redis-serwer --posterunek

Jak pokazano przy następujących wyjściach, serwer został uruchomiony w trybie Sentinel.

Ponadto, Redis Sentinels można również kolokować z serwerami Redis.

Profesjonaliści

• Automatyczna funkcja przełączania awaryjnego
• Proste i mniej czasochłonne do konfiguracji

Cons

• Sentinel potrzebuje oddzielnego klastra, jeśli nie jest połączony z węzłami serwera Redis
• Wykorzystanie węzłów głównych i niewolników jest niezrównoważone z powodu braku dostępnej opcji odchylenia
• Redis Sentinel jest systemem rozproszonym i obejmuje znaczną konserwację

Wysoka dostępność z klastrowaniem Redis

W przypadku najnowszych wydawnictw Redis do stosu Redis dodano komponent klastra. To wspiera:

• Sharding
• Replikacja
• Duża dostępność

Tak więc klaster Redis dotyczy kilku aspektów, których brakuje w poprzednich rozwiązaniach. Stało się to niezwykle korzystne dla dużych przedsiębiorstw, które generują i przechowują dużą ilość danych. Ponieważ Sharding rozpowszechnia dane między wieloma mistrzami, każdy ma podzbiór całej strony kluczowej. Daje to ogromny wzrost wydajności.

Jednocześnie replikacja jest dostępna w klastrach Redis, w których można skonfigurować wiele węzłów niewolników dla danego mistrza. Zwykle węzeł klastra powinien zawierać dokładnie jedną instancję serwera Redis. Ale możliwe jest skonfigurowanie powtórzenia krzyżowego poprzez wdrożenie wielu wystąpień w jednym węźle.

Ponadto opcja automatycznego przełączania awaryjnego jest zapewniana przez klastry Redis, w których węzeł niewolnika będzie promował mistrza. W konfiguracji klastra kworum nie jest zobowiązane do promowania nowego węzła głównego lub odłamku do pracy. Kworum węzłów głównych jest konieczne tylko do uruchomienia całego klastra.

Tak więc rozwiązanie klastra Redis może być postrzegane jako rozwiązanie dla wszystkich osób, które szukają odchylania, replikacji i wysokiej dostępności w swoich aplikacjach.

Profesjonaliści

• Obsługuje odłamek, co daje zwiększenie wydajności podczas zapytania do sklepu Redis Data Store.
• Zapewnia automatyczne rozwiązanie awaryjne
• Wsparcie Master-Replica

Cons

• Utrzymanie klastra może być znaczną ilością pracy
• Brak wsparcia bibliotecznego

Wniosek

Redis obsługuje wysoką dostępność za pomocą samodzielnego Redis, modelu Redis Sentinel i wbudowanego komponentu klastra. Wszystkie trzy rozwiązania mają swoje zalety i wady, jak omówiono powyżej. Ogólnie rzecz biorąc, Redis Sentinel jest opcją, jeśli szukasz tylko wysokiej dostępności i nie dbasz o wydajność. Ale jeśli szukasz równowagi między wydajnością a wysoką dostępnością z powtórzeniem, bez wątpienia klaster Redis jest najlepszy spośród wszystkich trzech.