Allereerst kunt u de standaardconfiguratie wijzigen als u weinig werk doet in
redis-trib.rb
in functie def check_create_parameters . U kunt één master- en één slave-replica instellen.
Het doel van deze configuratie is fouttolerantie. De slaves kunnen ook worden gebruikt om te lezen (ALLEEN LEZEN). In de drie masters zijn de hashslots gelijk verdeeld en met een load balancing-algoritme kun je de daadwerkelijke sleutels opnieuw verdelen. De stappen van een mogelijk algoritme dat de sleutels over de knooppunten verdeelt zijn (door mij getest en het werkt zoals verwacht):
- Vind de menigte van meesters
- Verkrijg het totale aantal sleutels dat ze bevatten
- Sla voor elk hoofdknooppunt de hostnaam, poort en het aantal sleutels op
- Bereken de sleutels die elke master moet hebben, zodat de verdeling van de sleutels in evenwicht is (totaal sleutels van cluster / aantal masters)
- Zoek welke hoofdknooppunten sleutels moeten nemen of geven en het totale aantal sleutels dat ze moeten geven/nemen
- Karakteriseer masters als bron- of doelknooppunten, afhankelijk van of ze respectievelijk sleutels ontvangen of weggeven
- Begin met migreren van bronknooppunt naar doelknooppunten, eerst de hashslots en dan de relevante sleutels en herhaal totdat alle masters hetzelfde aantal sleutels hebben
Dit algoritme helpt de responstijd te minimaliseren. Wat ik bedoel:
Met drie masters kan de responstijd worden geminimaliseerd. Als je een configuratie hebt met één master en deze master bevat bijvoorbeeld 30000 #keys, dan is de reactietijd om 1000keys tegelijk te krijgen> van een configuratie met 2 masters die elk 15000 kunnen bevatten.
Als je een sleutel aanmaakt in master1, dan krijg je een MOVED-fout als je die sleutel uit master2 probeert te bereiken (lezen). De oplossing is dus om een slimme client te maken die de hashslots toewijst aan het bijbehorende knooppunt. U kunt de sleutel dus alleen van master2 verwijderen als master2 uw verzoek doorstuurt naar de juiste master.
Ik hoop dat dat helpt.