Nejprve můžete změnit výchozí konfiguraci, pokud v
uděláte málo práceredis-trib.rb
ve funkci def check_create_parameters . Můžete nastavit jednu hlavní a jednu podřízenou repliku.
Účelem této konfigurace je odolnost proti chybám. Podřízené jednotky lze také použít pro čtení (POUZE PRO ČTENÍ). Ve třech masterech jsou hashsloty rovnoměrně rozmístěny a pomocí algoritmu pro vyvažování zátěže můžete znovu distribuovat skutečné klíče. Kroky možného algoritmu, který rozděluje klíče mezi uzly, jsou (testováno mnou a funguje podle očekávání):
- Najděte zástup mistrů
- Získejte celkový počet klíčů, které drží
- Pro každý hlavní uzel uložte název hostitele, port a počet klíčů
- Vypočítejte klíče, které musí každý master držet, aby bylo rozložení klíčů vyvážené (celkový počet klíčů clusteru / počet masterů)
- Zjistěte, které hlavní uzly musí vzít nebo dát klíče a celkový počet klíčů, které musí dát/vzít
- Charakterizujte předlohy jako zdrojové nebo cílové uzly v závislosti na tom, zda přijímají nebo rozdávají klíče
- Začněte migrovat ze zdrojového uzlu na cílové uzly, nejprve hashsloty a poté příslušné klíče a opakujte, dokud nebudou mít všichni hlavní servery stejný počet klíčů.
Tento algoritmus pomůže minimalizovat dobu odezvy. Co tím myslím:
Se třemi mastery lze minimalizovat dobu odezvy. Pokud máte konfiguraci s jedním masterem a tento master obsahuje například 30000 #klíčů, doba odezvy pro získání 1000 klíčů najednou je> z konfigurace se 2 mastery, z nichž každý pojme 15000.
Pokud vytvoříte klíč v master1, pak pokud se pokusíte dosáhnout (přečíst) tento klíč z master2, dostanete chybu MOVED. Řešením je tedy vytvoření chytrého klienta, který mapuje hashsloty na odpovídající uzel. Klíč z master2 tedy můžete odstranit pouze v případě, že master2 přesměruje váš požadavek na správného mastera.
Doufám, že to pomůže.