Redis v2.8.3 nepodporuje multi-master nastavení. Skutečná otázka však zní, proč ji chcete založit? Řečeno jinak, jakou výzvu/problém se snažíte vyřešit?
Zdá se, že problém, který se snažíte vyřešit, je, jak snížit zatížení sítě (více o tom níže) odstraněním čtení přes síť. Protože Redis (zatím) není multimaster, jediný způsob, jak to udělat, je nastavit každý aplikační server s hlavním a slave (k druhému masteru) – tj. celkem 4 instance Redis (a dvojnásobek RAM).
Jednoduchý scénář je, když každá aplikace aktualizuje pouze vzájemně se vylučující podmnožinu klíčů databáze. V tomto scénáři může být tento druh nastavení skutečně prospěšný (alespoň krátkodobě). Pokud se však obě aplikace mohou dotýkat všech kláves nebo pokud je i jen jedna klávesa „sdílená“ pro zápisy mezi aplikacemi, budete muset do svých aplikací zapečet logiku zamykání/řešení konfliktů/atd..., abyste konsolidovali místní hlavní a otrocké rozdíly (a to může být trochu přehnané). V obou případech však skončíte s příliš mnoha (tj. více než 1) přepsáním, což znamená přinejmenším více úsilí pro správce.
Všimněte si také, že umístěním aplikace a databáze na stejný server se vystavujete téměř jistému selhání škálovatelnosti. Co se stane, když budete pro své aplikace nebo Redis potřebovat více výpočetních zdrojů? Jak přidáte do mixu další aplikační server?
Což mě přivádí zpět ke skutečnému problému, který se snažíte vyřešit – zatížení sítě. Proč přesně je to problém? Jsou vaše aplikace tak náročné na propustnost nebo je síť tak tenká, že jste ochotni zajít tak daleko? Nebo je možná latence problém, který chcete vyřešit? Ať už je to jakkoli, doporučil jsem, abyste místo toho zvážili osvědčený design, konkrétně oddělení Redis od aplikací a jeho nasazení na vlastní zdroje. Pravda, síť vás udeří do obličeje a budete s tím muset pracovat (což dělá každý). Na druhou stranu budete mít větší flexibilitu a kontrolu nad svým mnohem jednodušším nastavením a to je podle mé knihy obrovský zisk.