memcache分布式原理解析

2021-08-16 18:21:09 字數 2004 閱讀 1745

所謂的分布式就是將不同的資料放在不同的伺服器上,獲取資料時需要根據路由從不同的伺服器上獲取。在memcache中,伺服器端並不支援分布式,而只是在客戶端程式中設定分布式。

如果有多個memcache伺服器,那麼他們之間並不互相通訊,資料也無法同步。所以在很多語言對memcache操作的類庫中都可以配置,然後根據相應的路由演算法決定將資料儲存在哪個伺服器中。

如果有多個memcache伺服器,每個伺服器上都存放著大量的資料,萬一有一台伺服器宕機,那麼它上面存的資料就會全部丟失,這也就是分布式的乙個弊端,不過就風險來講比放在乙個伺服器上要小得多。

上圖中可以看到,memcache api會呼叫路由演算法來決定將資料放在哪個伺服器上,同樣在讀取資料時呼叫路由演算法決定去哪個伺服器上取資料。

針對路由演算法,目前常見得就兩種,一種是餘數hash,一種是一致性hash演算法。

餘數hash:

將要儲存的k-v資料的key進行hash運算得到乙個值,然後根據memcache的數量進行整除取餘,根據餘數把資料放到對應的伺服器上。由於hash值得隨機性很大,所以伺服器上存放的資料也就比較均衡,一般不會造成大量資料只存放在一台伺服器上的情況。例如,username_099:xiaoming中key為username_099,通過hash運算得到的hashcode為21,memcache伺服器的數量為3個,那麼21%3=0,資料就會儲存在標號為0的伺服器中。讀取資料時也會根據這個演算法獲得hashcode,從而去0伺服器讀取資料。但是也會出現問題,如果多加入乙個伺服器,即4臺伺服器,那麼後續的資料再算出hashcode為21的話資料就會儲存到21%4=1的伺服器上,同樣在讀取原來key為username_099的資料時就會指引到1的伺服器上,從而導致無法獲取到資料的問題。

這種演算法有弊端,但是在python的memcache類庫中依然使用這種演算法。需要注意。

這個問題有解決方案,解決步驟為:

(1)在**訪問量低谷,通常是深夜,技術團隊加班,擴容、重啟伺服器

(2)通過模擬請求的方式逐漸預熱快取,使快取伺服器中的資料重新分布

一致性hash:

首先求出每個節點的hash值,可以根據ip port等進行求值,然後把值分布到乙個0-2^32的圓環上,

然後根據k-v的key值進行hash運算得到hashcode,判斷其處於哪兩個節點之間,然後決定存放在哪個伺服器上。

這個演算法雖然可以減輕一部分由於加伺服器帶來的問題。但是也無法完全避免。

consistent hashing

最大限度地抑制了hash鍵的重新分

布。另外要取得比較好的負載均衡的效果,往往在伺服器數量比較少的時候需要增加虛擬節點來保證伺服器能均勻的分布在圓環上。因為使用一般的hash方法,伺服器的對映地點的分布非常不均勻。

使用虛擬節點的思想,為每個物理節點(伺服器)在圓上分配100~200個點。這樣就能抑制分布不均勻,最大限度地減小伺服器增減時的快取重新分布。使用者資料對映在虛擬節點上,就表示使用者資料真正儲存位置是在該虛擬節點代表的實際物理伺服器上。

看到我加了乙個node4節點,只影響到了乙個key值的資料,本來這個key值應該是在node1伺服器上的,現在要去node4了。採用一致性hash演算法,的確也會影響到整個集群,但是影響的只是加粗的那一段而已,相比餘數hash演算法影響了遠超一半的影響率,這種影響要小得多。更重要的是,集群中快取伺服器節點越多,增加節點帶來的影響越小,很好理解。換句話說,隨著集群規模的增大,繼續命中原有快取資料的概率會越來越大,雖然仍然有小部分資料快取在伺服器中不能被讀到,但是這個比例足夠小,即使訪問資料庫,也不會對資料庫造成致命的負載壓力。

分布式事務原理解析

了解過tcc分布式事務的都知道它有三個階段 try,confirm,cancel,但很多文章就只有原理圖,和對原理圖的解釋,看一遍也留不下印象,這裡用實際場景舉個例子,說明tcc分布式事務原理 tcc分布式框架推薦 bytetcc,tcc transaction,himly 最終一致性方案一般都是有...

Redis分布式鎖原理解析

首先設定上鎖的方式,用setnx lockkey,currenttime timout 來表示設定鎖,其中lockkey為我們所需要爭取到的鎖,value值則由當前時間和設定的超時時間組成。當我們爭取到鎖後,進行常規操作即可,接下來我們討論競爭鎖失敗後的優化。首先我們去得到lockkey的value...

memcache分布式演算法

memcache服務是一套 分布式的快取記憶體系統,由 livejournal 的brad fitzpatrick開發,但目前被許多 使用以提公升 的訪問速度,尤其對於一些大型的 需要頻繁訪問 資料庫的 訪問速度提公升效果十分顯著 1 這是一套 開放源 軟體,以bsd license授權發布。mem...