Redis v2.8.3は、マルチマスターセットアップをサポートしていません。しかし、本当の問題は、なぜそれを設定したいのかということです。言い換えれば、どのような課題/問題を解決しようとしていますか？
あなたが解決しようとしている課題は、ネット上の読み取りを排除することによってネットワークの負荷をどのように減らすか（詳細は以下を参照）であるように見えます。 Redisは（まだ）マルチマスターではないため、これを行う唯一の方法は、各アプリサーバーにマスターをおよび設定することです。 スレーブ（他のマスターに対して）-つまり、合計4つのRedisインスタンス（およびRAMの2倍）。
単純なシナリオは、各アプリがデータベースのキーの相互に排他的なサブセットのみを更新する場合です。そのシナリオでは、この種の設定は実際に有益である可能性があります（少なくとも短期的には）。ただし、両方のアプリがすべてのキーに触れることができる場合、またはアプリ間で書き込みのために1つのキーだけが「共有」されている場合は、ローカルマスターを統合するために、ロック/競合解決などのロジックをアプリに組み込む必要があります。とスレーブの違い（そしてそれは少しやり過ぎかもしれません）。ただし、どちらの場合でも、Rediseが多すぎる（つまり、1を超える）ことになります。これは、少なくとも管理者の労力が増えることを意味します。
また、アプリとデータベースを同じサーバーに配置することで、ほぼ確実なスケーラビリティの障害が発生する可能性があることにも注意してください。アプリまたはRedisにさらに多くのコンピューティングリソースが必要になるとどうなりますか？ミックスにさらに別のアプリサーバーをどのように追加しますか？
これにより、解決しようとしている実際の問題、つまりネットワーク負荷に戻ることができます。なぜそれが問題なのですか？あなたのアプリはスループットが非常に重いですか、それともネットワークが非常に薄いので、そのような長さに進んでもかまいませんか？それとも、レイテンシーが解決したい問題ですか？場合によっては、代わりに、実績のあるデザインを検討することをお勧めします。つまり、Redisをアプリから分離し、独自のリソースに配置します。確かに、ネットワークはあなたの顔にぶつかり、あなたはそれを回避/回避する必要があります（これは他の誰もが行うことです）。一方で、はるかに単純なセットアップをより柔軟に制御できるようになります。私の本では、それは大きなメリットです。