一致性hash算法的特點
|
|-1.採用一致性哈希算法(consistent hashing)，將key和節點name同時hashing，然後進行映射匹配，採用的算法是MURMUR_HASH。
| 採用一致性哈希而不是採用簡單類似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的rehashing。
| 一致性哈希隻影響相鄰節點key分配，影響量小。
|
|-2.爲了避免一致性哈希隻影響相鄰節點造成節點分配壓力，
| ShardedJedis會對每個Redis節點根據名字(沒有，Jedis會賦予缺省名字)會虛擬化出160個虛擬節點進行散列。
| 根據權重weight，也可虛擬化出160倍數的虛擬節點。
| 用虛擬節點做映射匹配，可以在增加或減少Redis節點時，key在各Redis節點移動再分配更均勻，而不是隻有相鄰節點受影響。
|
|-3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，
| 這樣通過合理命名key，可以將一組相關聯的key放入同一個Redis節點，這在避免跨節點訪問相關數據時很重要。
虛擬節點
|
|-考量 Hash 算法的另一個指標是平衡性 (Balance) ,引入虛擬節點改善平衡性
|
|-一個實際節點對應了若干個“虛擬節點”，這個對應個數也成爲“複製個數”，“虛擬節點”在 hash 空間中以 hash 值排列。
Redis Sharding採用客戶端Sharding方式，服務端Redis還是一個個相對獨立的Redis實例節點，沒有做任何變動。
同時，我們也不需要增加額外的中間處理組件，這是一種非常輕量、靈活的Redis多實例集羣方法。
作爲輕量級客戶端sharding，處理Redis鍵值遷移是不現實的，這就要求應用層面允許Redis中數據丟失或從後端數據庫重新加載數據。
但有些時候，擊穿緩存層，直接訪問數據庫層，會對系統訪問造成很大壓力。
有沒有其它手段改善這種情況？Redis作者給出了一個比較討巧的辦法–presharding.
presharding及主備模式
|
|-即預先根據系統規模儘量部署好多個Redis實例，這些實例佔用系統資源很小，一臺物理機可部署多個，讓他們都參與sharding，
| 當需要擴容時，選中一個實例作爲主節點，新加入的Redis節點作爲從節點進行數據複製。
| 數據同步後，修改sharding配置，讓指向原實例的Shard指向新機器上擴容後的Redis節點，同時調整新Redis節點爲主節點，原實例可不再使用。
|
|-presharding是預先分配好足夠的分片，擴容時只是將屬於某一分片的原Redis實例替換成新的容量更大的Redis實例。
| 參與sharding的分片沒有改變，所以也就不存在key值從一個區轉移到另一個分片區的現象，只是將屬於同分片區的鍵值從原Redis實例同步到新Redis實例。
|
|-並不是只有增刪Redis節點引起鍵值丟失問題，更大的障礙來自Redis節點突然宕機。
| 在《Redis持久化》一文中已提到，
| 爲不影響Redis性能，儘量不開啓AOF和RDB文件保存功能，可架構Redis主備模式，主Redis宕機，數據不會丟失，備Redis留有備份。
|
|-這樣，我們的架構模式變成一個Redis節點切片包含一個主Redis和一個備Redis。在主Redis宕機時，備Redis接管過來，上升爲主Redis，繼續提供服務。
| 主備共同組成一個Redis節點，通過自動故障轉移，保證了節點的高可用性。
|
|-Redis Sentinel提供了主備模式下Redis監控、故障轉移功能達到系統的高可用性。