一、負載均衡
1.1.需求
如何實現一個會話粘滯（session sticky）的負載均衡算法？也就是說，在一次會話中的所有請求都路由到同一個服務器上。
1.2.解決方案
通過哈希算法對客戶端IP或會話ID計算哈希值，將取得的哈希值與服務器列表的大小進行取模運算，最終得到的值就是應該被路由到的服務器編號。這樣，就可以把同一個IP過來的請求都路由到同一個後端服務器上。
二、數據分片
2.1.如何統計“搜索關鍵詞”出現的次數？
①需求描述
假如我們有1T的日誌文件，這裏面記錄了用戶的搜索關鍵詞，我們想要快速統計出每個關鍵詞被搜索的次數，該怎麼做呢？
②問題分析
這個問題有兩個難點，第一個是搜索的日子很大，沒辦法放到一臺機器的內存中。第二個是隻用一臺機器來處理這麼巨大的數據，處理時間會很長。
③解決方案
先對數據進行分片，然後採用多臺（比如n臺）機器進行處理。具體做法：從搜索記錄的日誌文件中依次讀取每個關鍵詞，並通過哈希函數計算該關鍵詞的哈希值，然後跟機器的臺數n取模，最終得到值就是該關鍵詞應該被分到的機器編號，這樣相同的關鍵詞一定會被分配到同一臺機器上，數據分配完成後，由多臺機器並行進行統計，最後合併起來就是最終結果。
實際上，這裏的處理過程也是 MapReduce 的基本設計思想。
2.2.如何快速判斷圖片是否存在圖庫中？
①需求描述
假設現在我們的圖庫中有1億張圖片，如何快速判斷圖片是否在圖庫中？基本方式是給每個圖片去唯一表示（或者信息摘要），然後構建散列表。
②問題分析
很顯然，在單臺機器上構建散列表示行不通的，因爲單臺機器的內存有限，而1億張圖片構建散列表遠遠超過了單臺機器的內存上限。
②解決方案
準備n臺機器，讓每臺機器只維護一部分圖片對應的散列表。我們每次從圖庫中讀取一個圖片，計算唯一標識，然後與機器個數n求餘取模，得到的值就對應要分配的機器編號，然後將這個圖片的唯一表示和圖片路徑發往對應的機器構建散列表。
當我們要判斷一個圖片是否在圖庫中時，我們通過同樣的哈希算法，計算這個圖片的唯一表示，然後與機器個數n求餘取模。假設得到的值是k，那就去編號爲k的機器構建的散列表中查找。
如何估算給1億張圖片構建散列表大約需要多少臺機器？
散列表中每個數據單元包含兩個信息，哈希值和圖片文件的路徑。假設我們通過 MD5 來計算哈希值，那長度就是 128 比特，也就是 16 字節。文件路徑長度的上限是 256 字節，我們可以假設平均長度是 128 字節。如果我們用鏈表法來解決衝突，那還需要存儲指針，指針只佔用 8 字節。所以，散列表中每個數據單元就佔用 152 字節（這裏只是估算，並不準確）。
假設一臺機器的內存大小爲 2GB，散列表的裝載因子爲 0.75，那一臺機器可以給大約 1000 萬（2GB*0.75/152）張圖片構建散列表。所以，如果要對 1 億張圖片構建索引，需要大約十幾臺機器。在工程中，這種估算還是很重要的，能讓我們事先對需要投入的資源、資金有個大概的瞭解，能更好地評估解決方案的可行性。
實際上，針對這種海量數據的處理問題，我們都可以採用多機分佈式處理。藉助這種分片的思路，可以突破單機內存、CPU 等資源的限制。
三、分佈式存儲
3.1.什麼是分佈式存儲？
分佈式存儲就是將數據存儲在多臺機器上並提供高效的讀取、寫入支持。那如何決定將哪個數據放到哪個機器上呢？可以利用數據分片的思想，即通過哈希算法對數據取哈希值，然後對機器個數取模，這個最終值就是應該存儲的緩存機器編號。
3.2.遇到的問題是什麼？
如果數據持續增多，原來的機器數量已經不能滿足需求，就需要增加機器，這時就麻煩了，因爲所有的數據都需要重新哈希值進行再次分配。這就相當於，緩存中的數據一下子都失效了，所有的數據請求都會穿透緩存，直接去請求數據庫。這樣就可能發生雪崩效應，壓垮數據庫。
3.3.解決方案是什麼？
①這時，需要一種方法，使得新加入一個機器後，並不需要做大量的數據搬移。那就是在分佈式系統中應用非常廣泛的一致性哈希算法。
②一致性哈希算法的基本思想是什麼呢？爲了說清楚這個問題，我們假設有k個機器，數據的哈希值範圍是[0-MAX]，我們將整個範圍劃分成m個小區間（m遠大於k），每個機器複雜m/k個小區間。當有新機器加入的時候，我們就將某幾個小區間的數據，從原來的機器中搬移到新的機器中。這樣，既不用全部重新哈希、搬移數據，也保持了各個機器上數據量的均衡。
四、課後思考
這兩節我總共講了七個哈希算法的應用。實際上，我講的也只是冰山一角，哈希算法還有很多其他的應用，比如網絡協議中的 CRC 校驗、Git commit id 等等。除了這些，你還能想到其他用到哈希算法的地方嗎？