Först och främst kan du ändra standardkonfigurationen om du gör lite arbete i
redis-trib.rb
i funktionen def check_create_parameters . Du kan ställa in en master- och en slavreplik.
Syftet med denna konfiguration är feltolerans. Slavarna kan också användas för läsning (ENDAST läs). I de tre masterna är hashslots jämnt fördelade och med en lastbalanseringsalgoritm kan du omfördela och de faktiska nycklarna. Stegen för en möjlig algoritm som stör nycklarna bland noderna är (testade av mig och det fungerar som förväntat):
- Hitta skaran av mästare
- Få det totala antalet nycklar som de har
- Lagra värdnamn, port och antal nycklar för varje huvudnod
- Beräkna nycklarna som varje master måste hålla så att fördelningen av nycklar balanseras (totalt antal nycklar av kluster / antal masters)
- Ta reda på vilka masternoder som måste ta eller ge nycklar och det totala antalet nycklar som de måste ge/ta
- Karakterisera masters som käll- eller målnoder beroende på om de tar emot respektive ger bort nycklar
- Börja migrera från källnod till målnod, först hashslots och sedan relevanta nycklar och iterera tills alla masters har samma antal nycklar
Denna algoritm hjälper till att minimera svarstiden. Vad jag menar:
Med tre masters kan svarstiden minimeras. Om du har en konfiguration med en master och denna master rymmer till exempel 30000 #nycklar, är svarstiden för att få 1000nycklar på en gång från en konfiguration med 2 masters som rymmer 15000 vardera.
Om du skapar en nyckel i master1, om du försöker nå (läser) den nyckeln från master2 kommer du att få ett MOVED-fel. Så, lösningen är att skapa en smart klient som mappar hashslots till motsvarande nod. Således kan du ta bort nyckeln från master2 endast om master2 omdirigerar din begäran till rätt master.
Hoppas det hjälper.