線上的實際情況是總共有4台伺服器。現在主要用的是memcache，而且目前只用了61M左右的記憶體空間。公司的需求是逐步把整個網站的快取遷移到redis。
目前的想法是拿3台伺服器拿來做集群，每台伺服器配置一個Master實例。為了實現高可用，還需要為每台伺服器配置一個Slave實例。我想問的是，可不可以將Master實例和Slave實例配置到一個主機當中，以及這樣配置所帶來的影響？
還有一個想法是，只用2台伺服器，1台伺服器運行3個Master實例，另一台伺服器運行3個Slave實例。大家有更好的解決方案嗎？
還聽他們說，叢集的話至少要有3個主節點。用2個主節點不行嗎？
如果把master和slave放在同一台機器上，會有問題：
master和slave運行時都需要佔用內存，機器的內存可能不夠用
如果機器宕機，斷電，或者網路斷開，那麼master和slave沒有什麼高可用可言了。
master和slave最好都要放在不同的機器。
至於為什麼是3而不是2。這是集群選舉的時候的最佳策略。 redis3.0開始支援叢集。
一般，集群要對某個公共狀態達成共識，都需要集群中過半數的redis實例同意。
為什麼要過半數呢，因為要考慮集群發生腦裂(split-brain)的情況，也就是網路隔離(network-partition)，
過半數可以保證，無論網路怎麼隔離，無論腦怎麼裂，無論大集群被隔離成了多少個小集群，能夠提供服務(意味著有過半數的實例)的那個小集群裡，至少有一個實例是同步到最新的狀態資訊的。
在理解上面所說的過半數，然後才有背景來談談為什麼是奇數的問題
偶數也可以有過半數，例如，4個實例的集群，3就是一個過半數。
但為什麼還是奇數最好？
如果叢集有5個實例，那麼只能容忍2個實例的崩潰。
如果叢集中有6個實例，同樣也只能容忍2個實例的崩潰。
在相同的容忍度下，6個和5個有什麼區別：
由於集群間需要互相通信，實例越多，網路開銷越大
實例越多，5個實例的時候，發生3個實例崩潰的機率要小於6個實例的時候。
所以當然是奇數的性價比最高了。
是可以的，設定不同連接埠就行了，至於影響，我感覺也沒啥特別影響。
有3台的話，各跑一個master, 然後各自的slave放在不同的機器做成環形備份，不把雞蛋放在一個籃子裡。
ip資源夠的話，找ha中間件把高可用也做上。
生產環境不建議放在同一台實體機上。集群3台master說的是3.0集群，奇數節點保證投票能出確定結果
恩，那還是把Slave放在其他地方。
看看這個設計怎麼樣？
