線上的實際情況是總共有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放在其他地方。
看看這個設計怎麼樣?