Først og fremmest kan du ændre standardkonfigurationen, hvis du laver lidt arbejde i
redis-trib.rb
i funktionen def check_create_parameters . Du kan indstille en master og en slave replika.
Formålet med denne konfiguration er fejltolerance. Slaverne kan også bruges til at læse (KUN LÆSE). I de tre mastere er hashslots ligeligt fordelt og med en load balancing-algoritme kan du omfordele og de faktiske nøgler. Trinene i en mulig algoritme, der forstyrrer nøglerne blandt noderne, er (testet af mig, og det virker som forventet):
- Find mængden af mestre
- Få det samlede antal nøgler, de har
- For hver masterknude skal du gemme værtsnavnet, porten og antallet af nøgler
- Beregn de nøgler, som hver master skal have, så fordelingen af nøgler skal balanceres (samlet antal nøgler af klynge / antal mastere)
- Find hvilke masterknuder der skal tage eller give nøgler og det samlede antal nøgler, som de skal give/tage
- Karakteriser mastere som kilde- eller målknudepunkter afhængigt af, om de henholdsvis modtager eller giver nøgler væk
- Begynd at migrere fra kildeknude til målknude, først hashslots og derefter de relevante nøgler, og gentag indtil alle mastere har samme antal nøgler
Denne algoritme hjælper med at minimere responstiden. Hvad jeg mener:
Med tre mastere kan responstiden minimeres. Hvis du har en konfiguration med en master, og denne master har f.eks. 30000 #nøgler, er responstiden for at få 1000 nøgler på én gang fra en konfiguration med 2 mastere, der hver rummer 15000.
Hvis du opretter en nøgle i master1, så vil du få en MOVED fejl, hvis du prøver at nå (læse) den nøgle fra master2. Så løsningen er at skabe en smart klient, der kortlægger hashslots til den tilsvarende node. Du kan således kun slette nøglen fra master2 i tilfælde af at master2 omdirigerer din anmodning til den korrekte master.
Håber det hjælper.