Klaster Redis/równoważenie obciążenia

redis-trib.rb

w funkcji def check_create_parameters . Możesz ustawić jedną replikę główną i jedną podrzędną.

Celem tej konfiguracji jest odporność na uszkodzenia. Urządzenia podrzędne mogą być również używane do odczytu (TYLKO DO ODCZYTU). W trzech masterach, hashsloty są równomiernie rozmieszczone i dzięki algorytmowi równoważenia obciążenia można redystrybuować i rzeczywiste klucze. Kroki możliwego algorytmu, który dystrybuuje klucze między węzłami, to (przetestowane przeze mnie i działa zgodnie z oczekiwaniami):

1. Znajdź tłum mistrzów
2. Uzyskaj całkowitą liczbę kluczy, które trzymają
3. Dla każdego węzła głównego zapisz nazwę hosta, port i liczbę kluczy
4. Oblicz klucze, które każdy master musi posiadać, aby rozkład kluczy do zrównoważenia (łączna liczba kluczy klastra / liczba masterów)
5. Znajdź, które węzły główne muszą brać lub dawać klucze oraz całkowitą liczbę kluczy, które muszą dawać/odbierać
6. Scharakteryzuj mastery jako węzły źródłowe lub docelowe w zależności od tego, czy odpowiednio otrzymują, czy rozdają klucze
7. Rozpocznij migrację z węzła źródłowego do węzłów docelowych, najpierw na polach haszujących, a następnie na odpowiednich kluczach i iteruj, aż wszystkie urządzenia nadrzędne będą miały taką samą liczbę kluczy

Ten algorytm pomoże zminimalizować czas odpowiedzi. Co mam na myśli:

Dzięki trzem masterom czas odpowiedzi można zminimalizować. Jeśli masz konfigurację z jednym masterem i ten master przechowuje na przykład 30000 #kluczy, czas odpowiedzi na jednorazowy dostęp do 1000 kluczy wynosi> w przypadku konfiguracji z 2 masterami, która zawiera 15000 kluczy.

Jeśli utworzysz klucz w master1, to jeśli spróbujesz dotrzeć (odczytać) ten klucz z master2, otrzymasz błąd MOVED. Rozwiązaniem jest więc stworzenie inteligentnego klienta, który mapuje hashsloty do odpowiedniego węzła. W ten sposób możesz usunąć klucz z master2 tylko w przypadku, gdy master2 przekieruje twoją prośbę do właściwego mastera.

Mam nadzieję, że to pomoże.