一致性hash算法在內存數據庫中的應用

相關推薦

一致性hash算法在內存數據庫中的應用

　　業精于勤，荒于嬉;行成于思，毀于隨。學習編程的時候不僅要專心，更有用心。下面是小編整理的一致性hash算法在內存數據庫中的應用，希望對大家有用，更多消息請關注應屆畢業生網。

　　由于redis是單點，但是項目中不可避免的會使用多臺Redis緩存服務器，那么怎么把緩存的Key均勻的映射到多臺Redis服務器上，且隨著緩存服務器的增加或減少時做到最小化的減少緩存Key的命中率呢?這樣就需要我們自己實現分布式。

　　Memcached對大家應該不陌生，通過把Key映射到Memcached Server上，實現快速讀取。我們可以動態對其節點增加，并未影響之前已經映射到內存的Key與memcached Server之間的關系，這就是因為使用了一致性哈希。因為Memcached的哈希策略是在其客戶端實現的，因此不同的客戶端實現也有區別，以Spymemcache、Xmemcache為例，都是使用了KETAMA作為其實現。

　　一致性hash算法：

　　由于hash算法結果一般為unsigned int型，因此對于hash函數的結果應該均勻分布在[0,2^32-1]區間，如果我們把一個圓環用2^32 個點來進行均勻切割，首先按照hash(key)函數算出服務器(節點)的哈希值，并將其分布到0～2^32的圓環上。

　　用同樣的hash(key)函數求出需要存儲數據的鍵的哈希值，并映射到圓環上。然后從數據映射到的位置開始順時針查找，將數據保存到找到的第一個服務器(節點)上。key1、key2、key3和server1、server2通過hash都能在這個圓環上找到自己的位置，并且通過順時針的方式來將key定位到server。按上圖來說，key1和key2存儲到server1，而key3存儲到server2。如果新增一臺server，hash后在key1和key2之間，則只會影響key1(key1將會存儲在新增的server上)，其它不變。

　　【拓展閱讀】

PHP語言最令人“抓狂”的特性

　　糟糕的type安全

　　這個問題簡直可怕，首先舉個PHP程序員們喜聞樂見的例子：

　　(string)"false"

　　(int)0

　　請注意，這并不屬于那種某些PHP支持者所爭論的“函數副作用”的典型情況。畢竟t當中也包含著大量由于type轉換所引發的同類情況。事實上，這一行想表達的是：左側為字符串，右側為一個整數。只不過左側與右側內容完全相等。照這樣說來，如果讓PHP的設計者負責管理、世界上的每個人都能彼此和睦相處。

　　選擇太多，冗余太多

　　PHP語言的一大特色就是可做的事太多，做事的途徑同樣太多。每一行命令的結尾都可以通過數字符號或者雙斜線來進行注釋。無論是浮點數字還是雙精度數字都代表著同樣的含義。簡單的設計往往會被人們所忽略，因為大家在代碼貢獻過程中喜歡添加自己的小特性。這有點像依靠委員會體系進行設計，只不過該委員會從來沒考慮到過把其中的差異性剔除掉。

　　詭異的變量命名規則

　　把美元符號作為前綴實在不是個好主意。也許強制性地在所有變量前添加這個符號是為了更輕松地將其插入到模板當中，但這樣說來常數內容也同樣需要這么個符號啊—為什么實際上卻用不著呢?

　　CPU資源爭奪戰

　　對于32位計算設備來說，整數數值過大始終是個無法回避的難題。不過在另一方面，64位設備卻不會受此影響，也就是說代碼在不同設備上的運行狀態是不同的。大家可以在自己的筆記本上測試一下，我可以保證事實絕對是如此。但一旦把運行平臺轉換成服務器，情況則會再度變化。這時如果大家希望重現自己臺式機上的錯誤，結果恐怕要令各位失望。惟一的好消息是，32位設備將很可能最終消失。

　　SQL注入

　　將SQL注入這一安全漏洞的主要形式之一歸咎于PHP確實有失公允。人們在其它語言當中同樣會不慎輸入奇怪的SQL字符串。之所以將其納入文章，主要是考慮到PHP語言更容易讓該漏洞攫取數據并發送至MySQL—簡單是輕而易舉。雖然新手在使用任何一種語言時都可能犯下同樣的錯誤，但這類情況在PHP中出現的機率明顯要高得多得多。

　　不兼容式的變更太多太多

　　不同版本之間存在巨大差異，兼容性問題也絕不是小事。以Java或者t為代表的編程語言在快速發展的同時也犧牲了向下兼容的特性。事實上，老代碼在新設備上無法運行的問題并不少見。但這一切與PHP的情況其實不盡相同。在PHP方面，不同版本之間往往差別巨大，因此大家只能祈禱自己的服務器已經安裝了正確的版本，否則只有在出現嚴重問題時才能意識到大事不妙。總而言之，在查看服務器上是否有項目需要升級時，請優先把目光對準PHP。

一致性hash算法在內存數據庫中的應用

更多PHP相關文章推薦：