redis-cluster

1.redis單master架構的容量的瓶頸問題
單臺redis的緩存容量畢竟有限，若是超出的話，只能使用內存淘汰清除最近最久未使用的數據了

2.redis如何經過master橫向擴容支撐1T+數據量

三、redis的集羣架構
redis cluster

支撐N個redis master node，每一個master node均可以掛載多個slave node

讀寫分離的架構，對於每一個master來講，寫就寫到master，而後讀就從mater對應的slave去讀

高可用，由於每一個master都有salve節點，那麼若是mater掛掉，redis cluster這套機制，就會自動將某個slave切換成master

redis cluster（多master + 讀寫分離 + 高可用）

咱們只要基於redis cluster去搭建redis集羣便可，不須要手工去搭建replication複製+主從架構+讀寫分離+哨兵集羣+高可用
四、redis cluster 和 replication + sentinal哪一個好

若是你的數據量不多，主要是承載高併發高性能的場景，好比你的緩存通常就幾個G，單機足夠了

replication，一個mater，多個slave，要幾個slave跟你的要求的讀吞吐量有關係，而後本身搭建一個sentinal集羣，去保證redis主從架構的高可用性，就能夠了

redis cluster，主要是針對海量數據+高併發+高可用的場景，海量數據，若是你的數據量很大，那麼建議就用redis cluster

5.redis-cluster中最老土的hash算法和弊端（大量緩存重建）

解析：會有什麼問題呢？假設有3臺redis master節點，若是其中一臺master宕機了，那麼就會引起下面的問題：
①宕機的那臺redis上的緩存數據所有丟失，若是客戶端要訪問這些數據就要所有打到mysql上去，數據庫承受不了
②因爲宕機以後redis master節點數減小，那麼咱們作對key的hash值取模的時候就由原來的「hash值%3」變成「hash值%2」，這樣的話，其餘正常存活的redis master都會受到影響，咱們本來存的時候是按「hash值%3」存，可是取的時候是按「hash值%2」取，發生錯亂

六、一致性hash算法（自動緩存遷移）+虛擬節點（自動負載均衡）

具體在計算一致性hash時採用以下步驟：
首先求出redis服務器（節點）的哈希值，並將其配置到0～232的圓（continuum）上。
而後採用一樣的方法求出存儲數據的鍵的哈希值，並映射到相同的圓上。
而後從數據映射到的位置開始順時針查找，將數據保存到找到的第一個服務器上。若是超過232仍然找不到服務器，就會保存到第一臺redis服務器上。

　從上圖的狀態中添加一臺redis服務器。餘數分佈式算法因爲保存鍵的服務器會發生巨大變化而影響緩存的命中率，但Consistent Hashing中，只有在園（continuum）上增長服務器的地點順時針方向的第一臺服務器上的鍵會受到影響，以下圖所示：
　重點：只會影響插入節點的順時針方向的下一個節點上的鍵

七、redis cluster的hash slot算法

redis cluster有固定的16384個hash slot，對每一個key計算CRC16值，而後對16384取模，能夠獲取key對應的hash slot

redis cluster中每一個master都會持有部分slot，好比有3個master，那麼可能每一個master持有5000多個hash slot

hash slot讓node的增長和移除很簡單，增長一個master，就將其餘master的hash slot移動部分過去，減小一個master，就將它的hash slot移動到其餘master上去

移動hash slot的成本是很是低的

客戶端的api，能夠對指定的數據，讓他們走同一個hash slot，經過hash tag來實現
解析下圖：假設redis02宕機了，那麼也不會影響redis01和redis02，爲何呢？那是由於根據key的id找hash slot，而不是找redis機器，而redis01,03上的hash slot又沒有變化，固然不會影響啊，這個時候因爲redis02宕機，因此係統底層會把redis02上分配的hash slot轉移到剩下的redis存活的機器上，整個redis cluster仍然能夠對外提供服務

八、節點間的內部通訊機制

九、面向集羣的jedis內部實現原理

這是手動指定hash tag讓key落到指定的hash slot中

10.高可用性與主備切換原理（重要）