Redis的鍵rehash現象
什麼是鍵rehash現象
在redis中，鍵值以哈西表的方式進行存儲，在鍵值對的數目比較多時，哈西值衝突的次數就會變多，這會降低檢索效率。爲了減少哈西表中的地址衝突次數，redis會增加鍵值空間，重新定義鍵值對的映射地址，也就是進行所謂的rehash。
Redis的鍵rehash現象出現情形
若實例化 JedisShardInfo 時不設置節點名稱（name屬性），那麼當Redis節點列表的順序發生變化時，會發生“ 鍵 rehash 現象 ”
ps:本文基於Jedis2.6，非高版本或lettuce等其他框架
解決途徑之Sharded的initialize(…)方法實現
JedisShardInfo不設置節點名稱（name屬性），那麼當Redis節點列表的順序發生變化時，會發生“鍵 rehash 現象”；
唯一節點名稱+編號(推薦)
較好地一致性hash策略 是：唯一節點名稱+編號，不要考慮權重因素！
long hash = algo.hash(shardInfo.getName() + "*" + n)
所以， 在配置Redis服務列表時，必須要設置節點邏輯名稱（name屬性） 。
redis.server.list=192.168.1.31:6379: Shard-01 ,192.168.1.32:6379: Shard-02 ,192.168.1.33:6379: Shard-03 ,192.168.1.34:6379: Shard-04
節點IP:端口號+編號
Memcached Java Client，就是採用這種策略。
缺點： 因機房遷移等原因，可能導致節點IP發生改變！
this.algo.hash(shardInfo.getName() + “*” + shardInfo.getWeight() + n)
優點 ：這樣設計避免了上面"因節點順序調整而引發rehash"的問題，不推薦
缺點 ："節點名稱+權重"必須是唯一的，否則節點會出現重疊覆蓋！ 同時，"節點名稱+ 權重"必須不能被中途改變！
this.algo.hash(“SHARD-” + i + “-NODE-” + n)
優點 ：無，不推薦
缺點 ：將節點的順序索引i作爲hash的一部分！ 當節點順序被無意識地調整了，會觸發”鍵 rehash 現象” ，那就杯具啦！（"因節點順序調整而引發rehash"的問題）
關注Github：1/2極客
關注博客：御前提筆小書童
關注網站：HuMingfeng
關注公衆號：開發者的花花世界
