客戶端分片(sharding)
在 redis 推出官方集群技術(shù)之前 , sharding方案被廣泛的使用. 其主要的思想是客戶端進(jìn)行訪問時 , 采用哈希算法將Redis數(shù)據(jù)的key進(jìn)行散列 , 通過hash函數(shù) , 將特定key的請求映射到特定的節(jié)點(diǎn)上 . 這樣的話客戶端在每一次請求的時候 , 就知道該訪問哪一個節(jié)點(diǎn)惊窖。
Jedis客戶端已經(jīng)實(shí)現(xiàn)了客戶端分片功能
1.Jedis客戶端采用一致性哈希算法 , 將key和節(jié)點(diǎn)的name同時hashing , 然后進(jìn)行映射匹配 , 采用的算法是murmur_hash . 采用一致性哈希主要的原因是 , 當(dāng)增加或減少節(jié)點(diǎn)時 , 不會產(chǎn)生rehashing , 一致性哈希只影響相鄰的兩個節(jié)點(diǎn) , 關(guān)于一致性哈希算法 , 我會在后面的文章里展開房揭。
如下圖示 , node1 , node2 , node3 , 是完全獨(dú)立的三個實(shí)例 , 三個實(shí)例之間互不通訊
2.為了避免一致性哈希只影響相鄰節(jié)點(diǎn)造成節(jié)點(diǎn)分配壓力 , ShardedJedis會對Redis節(jié)點(diǎn)根據(jù)名字虛擬化出160個虛擬節(jié)點(diǎn)進(jìn)行散列 .根據(jù)權(quán)重 weight , 也可虛擬化出160倍數(shù)的虛擬節(jié)點(diǎn)泳炉。用虛擬節(jié)點(diǎn)再做映射匹配 , 可以在增加或者減少Redis節(jié)點(diǎn)時 , key在各Redis節(jié)點(diǎn)移動再分配更均勻 , 而不是只有相鄰節(jié)點(diǎn)受影響。
sharding + sentinel
通過上面的案例 , 我們成功的將對redis單個節(jié)點(diǎn)的訪問 , 分散到了三個節(jié)點(diǎn)上面 , 但是每個節(jié)點(diǎn)依然可能存在單點(diǎn)故障問題.
當(dāng)一個節(jié)點(diǎn)出現(xiàn)了故障的時候 , 我們的客戶端就無法訪問到這個節(jié)點(diǎn)內(nèi)的數(shù)據(jù) .
這個時候 , Redis為我們提供了Master-slave的主從復(fù)制功能 , 針對每一個主節(jié)點(diǎn) , 提供一個從節(jié)點(diǎn)進(jìn)行數(shù)據(jù)的復(fù)制 , 當(dāng)主節(jié)點(diǎn)宕機(jī)的時候 , 我們可以進(jìn)行主從節(jié)點(diǎn)的切換 , 以保障Redis服務(wù)的高可用 .
那么這個時候 , 我們是怎么進(jìn)行主從的切換的呢 ? sentinel集群 與 Redis集群 , 是可以完全獨(dú)立部署的 , 當(dāng)一個主節(jié)點(diǎn)掛掉以后 ,
Redis 自身提供了主從復(fù)制的功能 ,
