【集羣】Redis集羣設計原理

Redis集羣設計包括2部分：哈希Slot和節點主從

節點主從：

主從設計不算什麼新鮮玩意，在數據庫中咱們也常常用主歷來作讀寫分離，直接上圖：

 

圖上能看獲得的信息：

1， 只有1個Master，能夠有N個slaver，並且Slaver也能夠有本身的Slaver，因爲這種主從的關係決定他們是在配置階段就要指定他們的上下級關係，而不是Zookeeper那種平行關係是自主推優出來的。

2， 讀寫分離，Master只負責寫和同步數據給Slaver，Slaver承擔了被讀的任務，因此Slaver的擴容只能提升讀效率不能提升寫效率。

3， Slaver先將Master那邊獲取到的信息壓入磁盤，再load進內存，client端是從內存中讀取信息的，因此Redis是內存數據庫。

當一個新的Slaver加入到這個集羣時，會主動找Master來拜碼頭，Master發現新的小弟後將全量數據發送給新的Slaver，數據量越大性能消耗也就越大，因此儘可能避免在運行時作Slaver的擴容。

簡單總結下主從模式的設計：

優勢：讀寫分離，經過增長Slaver能夠提升併發讀的能力。

缺點：Master寫能力是瓶頸。

          雖然理論上對Slaver沒有限制可是維護Slaver開銷總將會變成瓶頸。

          Master的Disk大小也將會成爲整個Redis集羣存儲容量的瓶頸。

 

 

哈希Slot：

這個藝名看起來很文藝，但也不是什麼新技術，他的真名就叫分表分庫，再上一個圖：

 

圖上能看到的信息：

1， 對象保存到Redis以前先通過CRC16哈希到一個指定的Node上，例如Object4最終Hash到了Node1上。

2， 每一個Node被平均分配了一個Slot段，對應着0-16384，Slot不能重複也不能缺失，不然會致使對象重複存儲或沒法存儲。

3， Node之間也互相監聽，一旦有Node退出或者加入，會按照Slot爲單位作數據的遷移。例如Node1若是掉線了，0-5640這些Slot將會平均分攤到Node2和Node3上,因爲Node2和Node3自己維護的Slot還會在本身身上不會被從新分配，因此遷移過程當中不會影響到5641-16384Slot段的使用。

簡單總結下哈希Slot的優缺點：

缺點：每一個Node承擔着互相監聽、高併發數據寫入、高併發數據讀出，工做任務繁重

優勢：將Redis的寫操做分攤到了多個節點上，提升寫的併發能力，擴容簡單。

 

雙劍合併：

看到這裏你們也就發現了，主從和哈希的設計優缺點正好是相互彌補的，將圖一每一套主從對應到圖二中的每個Node，就是Redis集羣的終極形態，先Hash分邏輯節點，而後每一個邏輯節點內部是主從，如圖：

 

 

想擴展併發讀就添加Slaver，想擴展併發寫就添加Master，想擴容也就是添加Master，任何一個Slaver或者幾個Master掛了都不會是災難性的故障。轉自：https://blog.csdn.net/yejingtao703/article/details/78484151