前沿
有時候想想，分佈式領域真的很多東西都差不多，大家都會碰到，所以今天這個一致性hash是用在什麼場景呢？看看比人的博客，我也需要有自己的思考的東西。
解決什麼問題
- 場景一：如果一個數據庫表已經分庫分表，有4張表，那麼現在如何實現擴容，擴容到8張表？
- 場景二：8張表，如果要縮容，應該如何實現？
以上這些情況都可以通過 hash來解決，把數據hash 後，就可以實現擴容、縮容，新的問題：
- 擴容後，是不是所有數據都要重新hash？因爲有些數據要被分到其他節點上去了
巧了，一致性Hash就可以解決這個問題。
如何解決
普通的hash無法解決這個問題，一致性hash爲啥可以？一致性hash可以把節點映射到更多節點，並且是一個環形，以前是4臺機器，4個節點，hash節點也是4個，現在通過一致性hash可以把映射400個節點出來，0-100屬於節點1，100-200屬於節點2等等，如圖所示：
這樣做有什麼好處？一句話簡單總結：影響最小、且操作空間大。以下幾點：
- 如果擴容，只是圓環中的某一段分給了新節點，這樣隻影響來一個服務對應的節點數，其他節點不變
- 把數據進行hash賦給新節點，再把hash算法改掉，操作空間非常大，對業務無影響，無感知
- 如果實現完全的負載均衡，也可以更改節點到實際節點的映射關係
這裏面最重要的一點就是對業務無感知，而且是部分數據hash，並不是全量數據hash，影響也小。這裏不需要虛擬節點的概念，因爲虛擬節點到實體節點還有一層hash關係，這樣就不能保證擴容隻影響一個節點數據。
不用一致性hash來做擴容可以嘛？我覺得是可以的，就一個超大數組+hash就可以完成，只不過一致性hash也具備這個能力，一致性hash的虛擬節點在負載均衡有用。
舉例子啦
畫圖太費時間了，文字舉例：我們有一張表，分表爲4張，在要繼續擴容，擴容到8張表
- 0-100節點給數據庫1表
- 100-200節點給數據庫2表
- 200-300節點給數據庫3表
- 300-400節點給數據庫4表
這個時候新增4張表，我們可以把之前分配給每個表的100個節點分成2個50節點，這樣1張表的數據就分成了兩份
- 先把數據同步來到新節點，這樣只有一半的數據會被重定向去其他表，一半數據不變。
- 同步完成，替換爲新的節點跟表的映射關係。
這樣針對增刪改查都比較方便。如果一個機器被縮容了，那麼之前屬於他的節點可能就失效了。
負載均衡
負載均衡可以用一致性hash來解決，一致性hash有一個問題，如果不是2的倍數擴容，就存在負載不均衡的問題，某些節點的請求量就多了，也叫數據傾斜問題。
基於此，有人提出虛擬節點的概念，意思就是將一臺機器虛擬出很多節點，然後把這些節點放到hash環上，每臺服務器的虛擬節點交替出現，網上看到的圖片:
其實我有一個問題，爲啥要用節點去生成虛擬節點？而且虛擬節點的分佈也會導致不均衡的問題？完全可以不用這麼做呀，完全可以固定hash環上的節點數量，通過對hash環上節點數字再hash就可以了，可以按照以下流程來分析：
- 現在有3個服務器，我們可以確定再hash的數字是m=3，hash環上一共有n=100個節點
- 新增一個機器，m=4，節點數字%m 就可以確定服務器位置
- 減少一臺機器，m=2，節點數字%m 就可以確定服務器位置
這樣也是比較均衡的，而且解決了虛擬節點分佈的問題，唯一的問題是有可能n=7，m=5，這樣有些節點再hash後，某些機器上服務會少一個調用，不是完全平均的，但是當n非常大的時候，這種問題可以忽略。當然hash環上的節點也可以稱爲虛擬節點。
優點缺點
看到一個有趣的一句話：用錯了場景纔是缺陷，用對了，那是特性。一致性hash主要是解決數據分佈場景，普通的hash也是解決數據分佈的場景。
優點：
- 1、均衡
- 2、將節點與Hash算法解耦，而且通過交錯分配虛擬節點的方式解決了負載不均衡導致的緩存熱點問題
缺點：
- 1、虛擬節點只是爲了讓請求散落更均勻而存在，節點數量變化時虛擬節點數量也會變化，這種耦合限制的hash算法的進一步優化。比如在只有少量節點的集羣中出現宕機時，其虛擬節點仍然會把負載傳遞給下一個相鄰節點。
- 2、hash映射比較固定，如果認爲的要根據業務標籤來過hash，如何實現？
這個問題很有意思，應該把業務標示放在中間件框架中嘛？當然另外的角度就是是否允許實現靈活，靈活意味這可以實現特殊場景的兼容，也就是定製化考慮，似乎慢慢很多中間件也會思考這方面問題，看具體業務環境和公司環境吧，屬於決策的領域了。 - 3、不是完全的均勻負載
有一篇文章總結了hash的發展，其中用redis做例子講解，大家可以看看Redis的一致性Hash算法演進及優缺點分析
。
參考博客
