最快的內容查找算法-----暴雪的Hash算法

時間 2019-11-25

原文原文鏈接

暴雪公司有個經典的字符串的hash公式：先提一個簡單的問題，假若有一個龐大的字符串數組，而後給你一個單獨的字符串，讓你從這個數組中查找是否有這個字符串並找到它，你會怎麼作？
有一個方法最簡單，老老實實從頭查到尾，一個一個比較，直到找到爲止，我想只要學過程序設計的人都能把這樣一個程序做出來，但要是有程序員把這樣的程序交給用戶，我只能用無語來評價，或許它真的能工做，但也只能如此了。
最合適的算法天然是使用HashTable（哈希表），先介紹介紹其中的基本知識，所謂Hash，通常是一個整數，經過某種算法，能夠把一個字符串"壓縮" 成一個整數，這個數稱爲Hash，固然，不管如何，一個32位整數是沒法對應回一個字符串的，但在程序中，兩個字符串計算出的Hash值相等的可能很是小，下面看看在MPQ中的Hash算法。html

 1 unsigned long HashString(char *lpszFileName, unsigned long dwHashType)  
 2 {  
 3          unsigned char *key = (unsigned char *)lpszFileName;  
 4          unsigned long seed1 = 0x7FED7FED, seed2 = 0xEEEEEEEE;  
 5          int ch;  
 6          while(*key != 0)  
 7          {  
 8                   ch = toupper(*key );  
 9                   seed1 = cryptTable[(dwHashType < < 8) ch] ^ (seed1 seed2);  
10                   seed2 = ch seed1 seed2 (seed2 < < 5) 3;  
11           }  
12          return seed1;  
13 }

View Code

Blizzard的這個算法是很是高效的，被稱爲"One-Way Hash"，舉個例子，字符串"unitneutralacritter.grp"經過這個算法獲得的結果是0xA26067F3。
是否是把第一個算法改進一下，改爲逐個比較字符串的Hash值就能夠了呢，答案是，遠遠不夠，要想獲得最快的算法，就不能進行逐個的比較，一般是構造一個哈希表(Hash Table)來解決問題，哈希表是一個大數組，這個數組的容量根據程序的要求來定義，例如1024，每個Hash值經過取模運算 (mod)對應到數組中的一個位置，這樣，只要比較這個字符串的哈希值對應的位置有沒有被佔用，就能夠獲得最後的結果了，想一想這是什麼速度？是的，是最快的O(1)，如今仔細看看這個算法吧：程序員

int GetHashTablePos(char *lpszString, SOMESTRUCTURE *lpTable, int nTableSize)  
{  
       int nHash = HashString(lpszString), nHashPos = nHash % nTableSize;  
       if (lpTable[nHashPos].bExists && !strcmp(lpTable[nHashPos].pString, lpszString))  
              return nHashPos;  
       else  
              return -1; //Error value  
}

View Code

看到此，我想你們都在想一個很嚴重的問題："假如兩個字符串在哈希表中對應的位置相同怎麼辦？"，究竟一個數組容量是有限的，這種可能性很大。解決該問題的方法不少，我首先想到的就是用"鏈表"，感謝大學裏學的數據結構教會了這個百試百靈的法寶，我碰到的不少算法均可以轉化成鏈表來解決，只要在哈希表的每一個入口掛一個鏈表，保存全部對應的字符串就OK了。
事情到此彷佛有了完美的結局，假如是把問題獨自交給我解決，此時我可能就要開始定義數據結構而後寫代碼了。然而Blizzard的程序員使用的方法則是更精妙的方法。基本原理就是：他們在哈希表中不是用一個哈希值而是用三個哈希值來校驗字符串。
中國有句古話"再一再二不能再三再四"，看來Blizzard也深得此話的精髓，假如說兩個不一樣的字符串通過一個哈希算法獲得的入口點一致有可能，但用三個不一樣的哈希算法算出的入口點都一致，那幾乎能夠確定是不可能的事了，這個概率是1:18889465931478580854784，大概是10的 22.3次方分之一，對一個遊戲程序來講足夠安全了。
如今再回到數據結構上，Blizzard使用的哈希表沒有使用鏈表，而採用"順延"的方式來解決問題，看看這個算法：算法

 1 int GetHashTablePos(char *lpszString, MPQHASHTABLE *lpTable, int nTableSize)  
 2 {  
 3        const int HASH_OFFSET = 0, HASH_A = 1, HASH_B = 2;  
 4        int nHash = HashString(lpszString, HASH_OFFSET);  
 5        int nHashA = HashString(lpszString, HASH_A);  
 6        int nHashB = HashString(lpszString, HASH_B);  
 7        int nHashStart = nHash % nTableSize, nHashPos = nHashStart;  
 8        while (lpTable[nHashPos].bExists)  
 9        {  
10               if (lpTable[nHashPos].nHashA == nHashA && lpTable[nHashPos].nHashB == nHashB)  
11                      return nHashPos;  
12               else  
13                      nHashPos = (nHashPos 1) % nTableSize;  
14               if (nHashPos == nHashStart)  
15                      break;  
16        }  
17        return -1; //Error value  
18 }

View Code

1. 計算出字符串的三個哈希值（一個用來肯定位置，另外兩個用來校驗)
2. 察看哈希表中的這個位置
3. 哈希表中這個位置爲空嗎？假如爲空，則確定該字符串不存在，返回。
4. 假如存在，則檢查其餘兩個哈希值是否也匹配，假如匹配，則表示找到了該字符串，返回。
5. 移到下一個位置，假如已經越界，則表示沒有找到，返回。
6. 看看是否是又回到了原來的位置，假如是，則返回沒找到。
7. 回到3
怎麼樣，很簡單的算法吧，但確實是天才的idea, 其實最優秀的算法每每是簡單有效的算法。數組

原文連接：http://www.cnblogs.com/duzouzhe/archive/2009/10/14/1583359.html安全