本文作者：jeffhe，騰訊 IEG 開發工程師
提到hash，相信大多數同學都不會陌生，之前很火現在也依舊很火的技術區塊鏈背後的底層原理之一就是hash，下面就從hash算法的原理和實際應用等幾個角度，對hash算法進行一個講解。
1、什麼是Hash
Hash也稱散列、哈希，對應的英文都是Hash。基本原理就是把任意長度的輸入，通過Hash算法變成固定長度的輸出。這個映射的規則就是對應的Hash算法，而原始數據映射後的二進制串就是哈希值。活動開發中經常使用的MD5和SHA都是歷史悠久的Hash算法。
echo md5("這是一個測試文案");
// 輸出結果：2124968af757ed51e71e6abeac04f98d
在這個例子裏，這是一個測試文案是原始值，2124968af757ed51e71e6abeac04f98d 就是經過hash算法得到的Hash值。整個Hash算法的過程就是把原始任意長度的值空間，映射成固定長度的值空間的過程。
2、Hash的特點
一個優秀的hash算法，需要什麼樣的要求呢？
-
a)、從hash值不可以反向推導出原始的數據
這個從上面MD5的例子裏可以明確看到，經過映射後的數據和原始數據沒有對應關係 -
b)、輸入數據的微小變化會得到完全不同的hash值，相同的數據會得到相同的值
echo md5("這是一個測試文案"); // 輸出結果：2124968af757ed51e71e6abeac04f98d echo md5("這是二個測試文案"); // 輸出結果：bcc2a4bb4373076d494b2223aef9f702可以看到我們只改了一個文字，但是整個得到的hash值產生了非常大的變化。
-
c)、哈希算法的執行效率要高效，長的文本也能快速地計算出哈希值
-
d)、hash算法的衝突概率要小
由於hash的原理是將輸入空間的值映射成hash空間內，而hash值的空間遠小於輸入的空間。根據抽屜原理，一定會存在不同的輸入被映射成相同輸出的情況。那麼作爲一個好的hash算法，就需要這種衝突的概率儘可能小。
桌上有十個蘋果，要把這十個蘋果放到九個抽屜裏，無論怎樣放，我們會發現至少會有一個抽屜裏面放不少於兩個蘋果。這一現象就是我們所說的“抽屜原理”。抽屜原理的一般含義爲：“如果每個抽屜代表一個集合，每一個蘋果就可以代表一個元素，假如有n+1個元素放到n個集合中去，其中必定有一個集合裏至少有兩個元素。” 抽屜原理有時也被稱爲鴿巢原理。它是組合數學中一個重要的原理
3、Hash碰撞的解決方案
前面提到了hash算法是一定會有衝突的，那麼如果我們如果遇到了hash衝突需要解決的時候應該怎麼處理呢？比較常用的算法是鏈地址法和開放地址法。
3.1 鏈地址法
鏈表地址法是使用一個鏈表數組，來存儲相應數據，當hash遇到衝突的時候依次添加到鏈表的後面進行處理。
鏈地址法示意圖
鏈地址在處理的流程如下：
添加一個元素的時候，首先計算元素key的hash值，確定插入數組中的位置。如果當前位置下沒有重複數據，則直接添加到當前位置。當遇到衝突的時候，添加到同一個hash值的元素後面，行成一個鏈表。這個鏈表的特點是同一個鏈表上的Hash值相同。java的數據結構HashMap使用的就是這種方法來處理衝突，JDK1.8中，針對鏈表上的數據超過8條的時候，使用了紅黑樹進行優化。由於篇幅原因，這裏不深入討論相關數據結構，有興趣的同學可以參考這篇文章：
3.2 開放地址法
開放地址法是指大小爲 M 的數組保存 N 個鍵值對，其中 M > N。我們需要依靠數組中的空位解決碰撞衝突。基於這種策略的所有方法被統稱爲“開放地址”哈希表。線性探測法，就是比較常用的一種“開放地址”哈希表的一種實現方式。線性探測法的核心思想是當衝突發生時，順序查看錶中下一單元，直到找出一個空單元或查遍全表。簡單來說就是：一旦發生衝突，就去尋找下 一個空的散列表地址，只要散列表足夠大，空的散列地址總能找到。
線性探測法的數學描述是：h(k, i) = (h(k, 0) + i) mod m，i表示當前進行的是第幾輪探查。i=1時，即是探查h(k, 0)的下一個；i=2，即是再下一個。這個方法是簡單地向下探查。mod m表示：到達了表的底下之後，回到頂端從頭開始。
對於開放尋址衝突解決方法，除了線性探測方法之外，還有另外兩種比較經典的探測方法，二次探測（Quadratic probing）和雙重散列（Double hashing）。但是不管採用哪種探測方法，當散列表中空閒位置不多的時候，散列衝突的概率就會大大提高。爲了儘可能保證散列表的操作效率，一般情況下，我們會盡可能保證散列表中有一定比例的空閒槽位。我們用裝載因子（load factor）來表示空位的多少。
散列表的裝載因子=填入表中的元素個數/散列表的長度。裝載因子越大，說明衝突越多，性能越差。
3.3 兩種方案的demo示例
假設散列長爲8，散列函數H(K)=K mod 7，給定的關鍵字序列爲{32,14,23,2, 20}
當使用鏈表法時，相應的數據結構如下圖所示：
鏈表法demo
當使用線性探測法時，相應的數據結果如下圖所示：
開放地址-線性探測法
這裏的兩種算法的區別是2這個元素，在鏈表法中還是在節點2的位置上，但是在線性探測法遇到衝突時會將衝突數據放到下一個空的位置下面。
4、hash算法在日常活動中的應用
在日常運營活動中，我們活動開發經常遇到的應用場景是信息加密、數據校驗、負載均衡。下面分別對這三種應用場景進行講解。
4.1 信息加密
首先我們看一下信息加密的應用。2011年CSDN脫庫事件，導致超過600W的用戶的密碼泄露，讓人失望的是，CSDN是明文存儲用戶的註冊郵箱和密碼的。作爲用戶的非常隱私的信息，最簡單的保護措施就是對密碼進行hash加密。在客戶端對用戶輸入的密碼進行hash運算，然後在服務端的數據庫中保存用戶密碼的hash值。由於服務器端也沒有存儲密碼的明文，所以目前很多網站也就不再有找回密碼的功能了。
這裏也友情提示一下大家：如果在使用中發現某網站還有提供找回密碼的功能，就要好好擔心下這個網站的安全性了。
看到這裏有些同學會覺得那麼我們是不是對用戶輸入的密碼進行一次MD5加密就可以了呢，這樣就算惡意用戶知道了hash值，也沒有辦法拿到用戶的真實密碼。假設用戶的密碼是123456789，經過一次md5以後得到的值是:
25f9e794323b453885f5181f1b624d0b
那麼是不是使用了這個加密後的字符串來存密碼就萬無一失了呢，理想總是很豐滿，而現實總是很骨感的。
大家可以看一下這個網站：
https://www.cmd5.com/
這裏是該網站的相關介紹：
本站針對md5、sha1等全球通用公開的加密算法進行反向查詢，通過窮舉字符組合的方式，創建了明文密文對應查詢數據庫，創建的記錄約90萬億條，佔用硬盤超過500TB，查詢成功率95%以上，很多複雜密文只有本站纔可查詢。已穩定運行十餘年，國內外享有盛譽。
md5反查結果
那麼一般針對這種問題，我們的解決之道就是引入salt(加鹽)，即利用特殊字符（鹽）和用戶的輸入合在一起組成新的字符串進行加密。通過這樣的方式，增加了反向查詢的複雜度。但是這樣的方式也不是萬無一失，如果發生了鹽被泄露的問題，就需要所有用到的地方來重置密碼。
針對salt泄露的問題，其實還有一種解決辦法，即使用HMAC進行加密（Hash-based Message Authentication Code）。這種算法的核心思路是加密使用的key是從服務器端獲取的，每一個用戶的是不一樣的。如果發生了泄露，那麼也就是這一個用戶的會被泄露，不會影響到全局。
這裏也留給大家一個思考點，如果惡意用戶直接抓取了你的活動參與鏈接，也就是拿到了你計算後的hash值，那從技術的角度上說，我們還有沒有其他可以提升惡意用戶的違法成本呢？
4.2 數據校驗
- git commit id
使用過git的同學都應該清楚，每次git提交後都有一個commit id，比如:
19d02d2cc358e59b3d04f82677dbf3808ae4fc40
就是一次git commit的結果，那麼這個id是如何生成出來的呢？查閱了相關資料，使用如下代碼可以進行查看：
printf "commit %s\0" $(git cat-file commit HEAD | wc -c); git cat-file commit HEAD
git的commit id主要包括了以下幾部分內容：Tree 哈希，parent哈希、作者信息和本次提交的備註。
單次git commit相關信息
針對這些信息進行SHA-1 算法後得到值就是本次提交的commit id。簡單來講，就是對於單次提交的頭信息的一個校驗和。
Linux kernel開創者和Git的開發者——Linus說，Git使用了sha1並非是爲了安全性，而是爲了數據的完整性；它可以保證，在很多年後，你重新checkout某個commit時，一定是它多年前的當時的狀態，完全一摸一樣，完全值得信任。
但最新研究表明，理論上對其進行哈希碰撞（hash collision，不同的兩塊數據有相同的hash值）的攻擊可以在2^51（2的51次方）左右的次數內實現。不過由於commit id 是針對單個倉庫裏的，所以實際應用中我們可以認爲如果兩個文件的SHA-1值是相同的，那麼它們確是完全相同的內容。
注：對於git裏tree、parent等結構感興趣的同學，可以參考下這篇文章《Git 內部原理 - Git 對象》，這裏由於篇幅原因就不進行深入分析了。
-
版權校驗
在數據校驗方面的另一個應用場景就是版權的保護或者違禁信息的打擊，比如某個小視頻，第一個用戶上傳的時候，我們認爲是版權所有者，計算一個hash值存下來。當第二個用戶上傳的時候，同樣計算hash值，如果hash值一樣的話，就算同一個文件。這種方案其實也給用戶傳播違禁文件提高了一些門檻，不是簡單的換一個名字或者改一下後綴名就可以躲避掉打擊了。（當然這種方式也是可以繞過的，圖片的你隨便改一下顏色，視頻去掉一幀就又是完全不同的hash值了。注意：我沒有教你變壞，我只是和你在討論這個技術。。。）另外我們在社區裏，也會遇到玩家重複上傳同一張圖片或者視頻的情況，使用這種校驗的方式，可以有效減少cos服務的存儲空間。 -
大文件分塊校驗
使用過bt的同學都有經驗，在p2p網絡中會把一個大文件拆分成很多小的數據各自傳輸。這樣的好處是如果某個小的數據塊在傳輸過程中損壞了，只要重新下載這個塊就好。爲了確保每一個小的數據塊都是發佈者自己傳輸的，我們可以對每一個小的數據塊都進行一個hash的計算，維護一個hash List，在收到所有數據以後，我們對於這個hash List裏的每一塊進行遍歷比對。這裏有一個優化點是如果文件分塊特別多的時候，如果遍歷對比就會效率比較低。可以把所有分塊的hash值組合成一個大的字符串，對於這個字符串再做一次Hash運算，得到最終的hash（Root hash）。在實際的校驗中，我們只需要拿到了正確的Root hash，即可校驗Hash List，也就可以校驗每一個數據塊了。
大文件分塊示意圖
4.3 負載均衡
活動開發同學在應對高星級業務大用戶量參與時，都會使用分庫分表，針對用戶的openid進行hashtime33取模，就可以得到對應的用戶分庫分表的節點了。
活動分庫分表示意圖
如上圖所示，這裏其實是分了10張表，openid計算後的hash值取模10，得到對應的分表，在進行後續處理就好。對於一般的活動或者系統，我們一般設置10張表或者100張表就好。
下面我們來看一點複雜的問題，假設我們活動初始分表了10張，運營一段時間以後發現需要10張不夠，需要改到100張。這個時候我們如果直接擴容的話，那麼所有的數據都需要重新計算Hash值，大量的數據都需要進行遷移。如果更新的是緩存的邏輯，則會導致大量緩存失效，發生雪崩效應，導致數據庫異常。造成這種問題的原因是hash算法本身的緣故，只要是取模算法進行處理，則無法避免這種情況。針對這種問題，我們就需要利用一致性hash進行相應的處理了。
一致性hash的基本原理是將輸入的值hash後，對結果的hash值進行2^32取模，這裏和普通的hash取模算法不一樣的點是在一致性hash算法裏將取模的結果映射到一個環上。將緩存服務器與被緩存對象都映射到hash環上以後，從被緩存對象的位置出發，沿順時針方向遇到的第一個服務器，就是當前對象將要緩存於的服務器，由於被緩存對象與服務器hash後的值是固定的，所以，在服務器不變的情況下，一個openid必定會被緩存到固定的服務器上，那麼，當下次想要訪問這個用戶的數據時，只要再次使用相同的算法進行計算，即可算出這個用戶的數據被緩存在哪個服務器上，直接去對應的服務器查找對應的數據即可。這裏的邏輯其實和直接取模的是一樣的。如下圖所示：
初始3臺機器的情況
初始情況如下：用戶1的數據在服務器A裏，用戶2、3的數據存在服務器C裏，用戶4的數據存儲在服務器B裏
下面我們來看一下當服務器數量發生變化的時候，相應影響的數據情況：
-
服務器縮容
服務器縮容
服務器B發生了故障，進行剔除後，只有用戶4的數據發生了異常。這個時候我們需要繼續按照順時針的方案，把緩存的數據放在用戶A上面。
-
服務器擴容
同樣的，我們進行了服務器擴容以後，新增了一臺服務器D，位置落在用戶2和3之間。按照順時針原則，用戶2依然訪問的是服務器C的數據，而用戶3順時針查詢後，發現最近的服務器是D，後續數據就會存儲到d上面。
服務器擴容示意圖
-
虛擬節點
當然這只是一種理想情況，實際使用中，由於服務器節點數量有限，有可能出現分佈不均勻的情況。這個時候會出現大量數據都被映射到某一臺服務器的情況，如下圖左側所示。爲了解決這個問題，我們採用了虛擬節點的方案。虛擬節點是實際節點（實際的物理服務器）在hash環上的複製品，一個實際節點可以對應多個虛擬節點。虛擬節點越多，hash環上的節點就越多，數據被均勻分佈的概率就越大。
虛擬節點示意圖
如右圖所示，B、C、D 是原始節點複製出來的虛擬節點，原本都要訪問機器D的用戶1、4，分別被映射到了B,D。通過這樣的方式，起到了一個服務器均勻分佈的作用。
5、幾種hash算法的擴展應用
下面介紹幾種大家可能不經常遇到的應用，由於篇幅原因，不做深入介紹，只拋磚引玉。
5.1 SimHash
simHash是google用於海量文本去重的一種方法，它是一種局部敏感hash。那什麼叫局部敏感呢，假定兩個字符串具有一定的相似性，在hash之後，仍然能保持這種相似性，就稱之爲局部敏感hash。普通的hash是不具有這種屬性的。simhash被Google用來在海量文本中去重。
simHash算法的思路大致如下：
-
將Doc進行關鍵詞抽取(其中包括分詞和計算權重)，抽取出n個(關鍵詞，權重)對， 即圖中的多個(feature, weight)。記爲 feature_weight_pairs = [fw1, fw2 … fwn]，其中 fwn = (feature_n,weight_n)。
-
對每個feature_weight_pairs中的feature進行hash。然後對hash_weight_pairs進行位的縱向累加，如果該位是1，則+weight,如果是0，則-weight，最後生成bits_count個數字，大於0標記1，小於0標記0
-
最後轉換成一個64位的字節，判斷重複只需要判斷他們的特徵字的距離是不是<n (n根據經驗一般取3)，就可以判斷兩個文檔是否相似。
SimHash計算流程
如下圖所示，當兩個文本只有一個字變化時，如果使用普通Hash則會導致兩次的結果發生較大改變，而SimHash的局部敏感特性，會導致只有部分數據發生變化。
SimHash結果
5.2 GeoHash
GeoHash將地球作爲爲一個二維平面進行遞歸分解。每個分解後的子塊在一定經緯度範圍內擁有相同的編碼。以下圖爲例，這個矩形區域內所有的點（經緯度座標）都共享相同的GeoHash字符串，這樣既可以保護隱私（只表示大概區域位置而不是具體的點），又比較容易做緩存。
GeoHash示意圖
下面以一個例子來理解下這個算法，我們對緯度39.3817進行逼近編碼 ：
-
地球緯度區間是[-90,90]，對於這個區間進行二分劃分左區間[-90,0), 右區間[0,90]。39.3817屬於右區間，標記爲1
-
將右區間[0,90]繼續進行劃分，左區間[0,45) ,右區間[45,90]。39.3817屬於左區間，標記爲0
-
遞歸上面的過程，隨着每次迭代，區間[a，b]會不斷接近39.3817。遞歸的次數決定了生成的序列長度。
-
對於經度做同樣的處理。得到的字符串，偶數位放經度，奇數位放緯度，把2串編碼組合生成新串。對於新串轉成對應10進制查出實際的base32編碼就是類似WX4ER的hash值。
整體遞歸過程如下表所示：
這裏有一篇文章詳細介紹了GeoHash，有興趣的同學可以移步這裏：
5.3 布隆過濾器
布隆過濾器被廣泛用於黑名單過濾、垃圾郵件過濾、爬蟲判重系統以及緩存穿透問題。對於數量小，內存足夠大的情況，我們可以直接用hashMap或者hashSet就可以滿足這個活動需求了。但是如果數據量非常大，比如5TB的硬盤上放滿了用戶的參與數據，需要一個算法對這些數據進行去重，取得活動的去重參與用戶數。這種時候，布隆過濾器就是一種比較好的解決方案了。
布隆過濾器其實是基於bitmap的一種應用，在1970年由布隆提出的。它實際上是一個很長的二進制向量和一系列隨機映射函數，用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率和刪除困難，主要用於大數據去重、垃圾郵件過濾和爬蟲url記錄中。核心思路是使用一個bit來存儲多個元素，通過這樣的方式來減少內存的消耗。通過多個hash函數，將每個數據都算出多個值，存放在bitmap中對應的位置上。
布隆過濾器的原理見下圖所示：
布隆過濾器原理示意
上圖所示的例子中，數據a、b、c經過三次hash映射後，對應的bit位都是1，表示這三個數據已經存在了。而d這份數據經過映射後有一個結果是0，則表明d這個數據一定沒有出現過。布隆過濾器存在假陽率（判定存在的元素可能不存在）的問題，但是沒有假陰率（判斷不存在的原因可能存在）的問題。即對於數據e，三次映射的結果都是1，但是這份數據也可能沒有出現過。
誤判率的數據公式如下所示：
其中，p是誤判率，n是容納的元素，m是需要的存儲空間。由公示可以看出，布隆過濾器的長度會直接影響誤報率，布隆過濾器越長其誤報率越小。哈希函數的個數也需要權衡，個數越多則布隆過濾器 bit 位置位 1 的速度越快，且布隆過濾器的效率越低；但是如果太少的話，則會導致誤報率升高。
6、總結
Hash算法作爲一種活動開發經常遇到的算法，我們在使用中不僅僅要知道這種算法背後真正的原理，纔可以在使用上做到有的放矢。