相關歷史文章（閱讀本文之前，您可能需要先看下之前的系列 ）

色談Java序列化：女孩子慎入 - 第280篇

煩不煩，別再問我時間復雜度了：這次不色，女孩子進來吧 - 第281篇

雙向鏈表，比西天還遠？- 第282篇

面試不再怕，讓LRU無處可逃 - 第283篇

愛我，就要懂我 – Memcached- 第284篇

內存管理，難于上青天？- memcached - 第285篇

你懂她，可惜你不懂我「LRU 」- Memcached- 第286篇

悟纖：師傅，這個不是在之前就說過了，這個我懂。

師傅：恩赫，你懂？那我問你下memcached分布式使用的是什么算法？

悟纖：？？？難道不是hash一下就可以了嘛。

師傅：要是這么簡單就能理解了，我還會在嘮叨一遍嘛。

悟纖：那徒兒洗耳恭聽。

一、Memcached分布式是如何實現的

memcached本身是一個非常輕量級的服務，不支持主輔同步，也沒有集群的概念。但為了可擴展性，memcached服務器端和 memcached 客戶端結合起來可以構成一個分布式系統。

在memcached分布式系統中，各個 memcached 節點之間無須通信，所以擴展性非常好。

->Memcached的分布式特點：

?1>: 服務器端不關心分布式：服務端的各個Memcached都是獨立部署，之間不相互通信，這樣服務端部署多個Memcached就很簡單。

?2>: 依靠客戶端來實現分布式：最簡單的方式就是客戶端擁有服務端所有連接地址，客戶端通過key的hash值獲取到對應的Memcached。

二、分布式算法

當向memcached集群存入/取出key/value時，memcached客戶端程序根據一定的算法計算存入哪臺服務器，然后再把key/value值存到此服務器中。也就是說，存取數據分二步走，第一步，選擇服務器，第二步存取數據。

常用的算法有兩種: 余數計算分散法 和 一致性Hash算法。

2.1 余數計算分散法

標準的memcached分布式算法

CRC($key)%N

BTW：CRC是一循環冗余算法，N：memcached服務器個數。

客戶端首先根據key來計算CRC , 然后結果對服務器取模得到memcached服務器節點。

這種算法取余計算簡單，分散效果好，但是缺點是如果某一臺機器宕機，那么應該落在該機器的請求就無法得到正確的處理，這時需要將當掉的服務器從算法從去除，此時候會有 (N-1) 的服務器的緩存數據需要重新進行計算；如果新增一臺機器，會有 (N+1)的服務器的緩存數據需要進行重新計算。對于系統而言，這通常是不可接受的顛簸（因為這意味著大量緩存的失效或者數據需要轉移）。

2.2 一致性hash算法

將server的hash值分配至0~2^32的圓環上, 用同樣的方法求出存儲數值鍵的hash值并映射到圓上. 然后從數據映射到的位置開始順時針查找, 將數據存放至找到的第一臺服務器上。如果超過0~2^32還找不到, 則將數據存放至第一臺服務器。

2.2.1 算法過程

（1）先構造一個長度為0~2^32（2的32次冪）個的整數環（又稱：一致性Hash環），根據節點名稱的Hash值將緩存服務器節點放置在這個Hash環中，如上圖中的node1，node2等；

（2）根據需要緩存的數據的KEY值計算得到其Hash值，如上圖中右半部分的“鍵”，計算其Hash值后順時針離node2近；

（3）在Hash環上順時針查找距離這個KEY的Hash值最近的緩存服務器節點，完成KEY到服務器的Hash映射查找，如上圖中離右邊這個鍵的Hash值最近的順時針方向的服務器節點是node2，因此這個KEY會到node2中讀取數據；

2.2.2 添加節點

當緩存服務器集群需要擴容的時候，只需要將新加入的節點名稱（如node5）的Hash值放入一致性Hash環中，由于KEY總是順時針查找距離其最近的節點，因此新加入的節點只影響整個環中的一部分。如下圖中所示，添加node5后，只影響右邊逆時針方向的三個Key/Value對數據，只占整個Hash環中的一小部分。

BTW：刪節節點或者服務器down機，影響的也只是順時針的下一個節點。

2.2.3 算法優缺點

優點：動態的增刪節點，服務器down機，影響的只是順時針的下一個節點

缺點：當服務器進行hash后值較為接近會導致在圓環上分布不均勻，進而導致key的分布、服務器的壓力不均勻。若中間某一權重較大的serverdown機，命中率下降明顯；

2.2.4 算法對比

我們可以與之前的普通余數Hash作對比：采用一致性Hash算法時，當3臺服務器擴容到4臺時，可以繼續命中原有緩存數據的概率為75%，遠高于普通余數Hash的25%，而且隨著集群規模越大，繼續命中原有緩存數據的概率也會隨之增大。當100臺服務器增加1臺時，繼續命中的概率是99%。雖然，仍有小部分數據緩存在服務器中無法被讀取到，但是這個比例足夠小，通過訪問數據庫也不會對數據庫造成致命的負載壓力。

2.3 優化一致性hash算法（虛擬節點）

服務器的映射地點的分布非常的不均勻, 導致數據訪問傾斜, 大量的key被映射到同一臺服務器上，這時候需要在一致性哈希算法的基礎上引入虛擬節點：

引入虛擬節點的思想，解決一致性hash算法分布不均導致負載不均的問題。一個真實節點對應若干個虛擬節點，當key被映射到虛擬節點上時，則被認為映射到虛擬節點所對應的真實節點上。

BTW：引入虛擬節點的思想，每個物理節點對應圓環上若干個虛擬節點（比如200~300個），當key hash到虛擬節點，就會存儲到實際的物理節點上，有效的實現了負載均衡。

三、悟纖小結

師傅：徒兒，聽明白沒有，來，你給大家來個總結吧。
悟纖：好的，師傅，您休息下，喝點水。

總結：

（1）Memcached的分布式實現原理：服務端之間互不通信，分布式的實現是通過客戶端使用一致性Hash算法進行實現的。
（2）分布式算法：余數計算分散法和一致性hash算法。
（3）余數分散法存在的問題：當節點變動的時候，緩存數據需要重新計算，命中率就會受到很大影響。
（4）一致性hash算法存在問題：數據分布不均勻，負載不均衡。
（5）優化的一致hash算法原理：加入虛擬節點，物理節點映射到若干個虛擬節點上，從而使得數據分布均衡分布在虛擬節點上，以此來實現負載均衡。

我就是我，是顏色不一樣的煙火。 我就是我，是與眾不同的小蘋果。學院中有Spring Boot相關的課程：
à悟空學院：https://t.cn/Rg3fKJD
SpringBoot視頻：http://t.cn/A6ZagYTi
Spring Cloud視頻：http://t.cn/A6ZagxSR
SpringBoot Shiro視頻：http://t.cn/A6Zag7IV
SpringBoot交流平臺：https://t.cn/R3QDhU0
SpringData和JPA視頻：http://t.cn/A6Zad1OH
SpringSecurity5.0視頻：http://t.cn/A6ZadMBe
Sharding-JDBC分庫分表實戰：http://t.cn/A6ZarrqS
分布式事務解決方案「手寫代碼」：http://t.cn/A6ZaBnIr

總結

以上是生活随笔為你收集整理的memcached客户端_分布式算法真是吊炸天 – memcached - 第287篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。