您好,登錄后才能下訂單哦!
這篇文章主要為大家展示了“PHP實現(xiàn)一致性哈希算法的示例分析”,內(nèi)容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領(lǐng)大家一起研究并學習一下“PHP實現(xiàn)一致性哈希算法的示例分析”這篇文章吧。
在做服務器負載均衡時候可供選擇的負載均衡的算法有很多,包括: 輪循算法(Round Robin)、哈希算法(HASH)、最少連接算法(Least Connection)、響應速度算法(Response Time)、加權(quán)法(Weighted )等。其中哈希算法是最為常用的算法.
典型的應用場景是: 有N臺服務器提供緩存服務,需要對服務器進行負載均衡,將請求平均分發(fā)到每臺服務器上,每臺機器負責1/N的服務。
常用的算法是對hash結(jié)果取余數(shù) (hash() mod N
):對機器編號從0到N-1,按照自定義的hash()算法,對每個請求的hash()值按N取模,得到余數(shù)i,然后將請求分發(fā)到編號為i的機器。但這樣的算法方法存在致命問題,如果某一臺機器宕機,那么應該落在該機器的請求就無法得到正確的處理,這時需要將當?shù)舻姆掌鲝乃惴◤娜コ?,此時候會有(N-1)/N的服務器的緩存數(shù)據(jù)需要重新進行計算;如果新增一臺機器,會有N /(N+1)的服務器的緩存數(shù)據(jù)需要進行重新計算。對于系統(tǒng)而言,這通常是不可接受的顛簸(因為這意味著大量緩存的失效或者數(shù)據(jù)需要轉(zhuǎn)移)。那么,如何設(shè)計一個負載均衡策略,使得受到影響的請求盡可能的少呢?
在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了Consistent Hashing算法,可以說Consistent Hashing 是分布式系統(tǒng)負載均衡的首選算法。
1、Consistent Hashing算法描述
下面以Memcached中的Consisten Hashing算法為例說明。
由于hash算法結(jié)果一般為unsigned int型,因此對于hash函數(shù)的結(jié)果應該均勻分布在[0,232-1]間,如果我們把一個圓環(huán)用232 個點來進行均勻切割,首先按照hash(key)函數(shù)算出服務器(節(jié)點)的哈希值, 并將其分布到0~232的圓上。
用同樣的hash(key)函數(shù)求出需要存儲數(shù)據(jù)的鍵的哈希值,并映射到圓上。然后從數(shù)據(jù)映射到的位置開始順時針查找,將數(shù)據(jù)保存到找到的第一個服務器(節(jié)點)上。
Consistent Hashing原理示意圖
新增一個節(jié)點的時候,只有在圓環(huán)上新增節(jié)點逆時針方向的第一個節(jié)點的數(shù)據(jù)會受到影響。刪除一個節(jié)點的時候,只有在圓環(huán)上原來刪除節(jié)點順時針方向的第一個節(jié)點的數(shù)據(jù)會受到影響,因此通過Consistent Hashing很好地解決了負載均衡中由于新增節(jié)點、刪除節(jié)點引起的hash值顛簸問題。
Consistent Hashing添加服務器示意圖
虛擬節(jié)點(virtual nodes):之所以要引進虛擬節(jié)點是因為在服務器(節(jié)點)數(shù)較少的情況下(例如只有3臺服務器),通過hash(key)算出節(jié)點的哈希值在圓環(huán)上并不是均勻分布的(稀疏的),仍然會出現(xiàn)各節(jié)點負載不均衡的問題。虛擬節(jié)點可以認為是實際節(jié)點的復制品(replicas),本質(zhì)上與實際節(jié)點實際上是一樣的(key并不相同)。引入虛擬節(jié)點后,通過將每個實際的服務器(節(jié)點)數(shù)按照一定的比例(例如200倍)擴大后并計算其hash(key)值以均勻分布到圓環(huán)上。在進行負載均衡時候,落到虛擬節(jié)點的哈希值實際就落到了實際的節(jié)點上。由于所有的實際節(jié)點是按照相同的比例復制成虛擬節(jié)點的,因此解決了節(jié)點數(shù)較少的情況下哈希值在圓環(huán)上均勻分布的問題。
虛擬節(jié)點對Consistent Hashing結(jié)果的影響
從上圖可以看出,在節(jié)點數(shù)為10個的情況下,每個實際節(jié)點的虛擬節(jié)點數(shù)為實際節(jié)點的100-200倍的時候,結(jié)果還是很均衡的。
第3段中有這些文字:“但這樣的算法方法存在致命問題,如果某一臺機器宕機,那么應該落在該機器的請求就無法得到正確的處理,這時需要將當?shù)舻姆掌鲝乃惴◤娜コ?,此時候會有(N-1)/N的服務器的緩存數(shù)據(jù)需要重新進行計算;”
為何是 (N-1)/N 呢?解釋如下:
比如有 3 臺機器,hash值 1-6 在這3臺上的分布就是:
host 1: 1 4
host 2: 2 5
host 3: 3 6
如果掛掉一臺,只剩兩臺,模數(shù)取 2 ,那么分布情況就變成:
host 1: 1 3 5
host 2: 2 4 6
可以看到,還在數(shù)據(jù)位置不變的只有2個: 1,2,位置發(fā)生改變的有4個,占共6個數(shù)據(jù)的比率是 4/6 = 2/3這樣的話,受影響的數(shù)據(jù)太多了,勢必太多的數(shù)據(jù)需要重新從 DB 加載到 cache 中,嚴重影響性能
【consistent hashing 的辦法】
上面提到的 hash 取模,模數(shù)取的比較小,一般是負載的數(shù)量,而 consistent hashing 的本質(zhì)是將模數(shù)取的比較大,為 2的32次方減1,即一個最大的 32 位整數(shù)。然后,就可以從容的安排數(shù)據(jù)導向了,那個圖還是挺直觀的。
以上是“PHP實現(xiàn)一致性哈希算法的示例分析”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學習更多知識,歡迎關(guān)注億速云行業(yè)資訊頻道!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。