data_structure_and_algorithm -- 雜湊演算法（下）：雜湊演算法在分散式系統中有哪些應用？
今天主要看一下雜湊演算法的應用（二），主要參考：前谷歌工程師王爭的課程，感興趣可以通過下面方式微信掃碼購買：
上一節： ofollow,noindex" target="_blank">data_structure_and_algorithm -- 雜湊演算法（上）：如何防止資料庫中的使用者被脫庫？ 介紹了雜湊演算法的四個應用，它們分別是：安全加密、資料校驗、唯一標識、雜湊函式。今天，我們再來看剩餘三種應用：負載均衡、資料分片、分散式儲存。
你可能已經發現，這三個應用都跟分散式系統有關。沒錯，今天我就帶你看下，雜湊演算法是如何解決這些分散式問題的。
應用五：負載均衡
我們知道，負載均衡演算法有很多，比如輪詢、隨機、加權輪詢等。那如何才能實現一個會話粘滯（session sticky）的負載均衡演算法呢？也就是說，我們需要在同一個客戶端上，在一次會話中的所有請求都路由到同一個伺服器上。
最直接的方法就是，維護一張對映關係表，這張表的內容是客戶端 IP 地址或者會話 ID 與伺服器編號的對映關係。客戶端發出的每次請求，都要先在對映表中查詢應該路由到的伺服器編號，然後再請求編號對應的伺服器。這種方法簡單直觀，但也有幾個弊端：
（1）如果客戶端很多，對映表可能會很大，比較浪費記憶體空間；
（2）客戶端下線、上線，伺服器擴容、縮容都會導致對映失效，這樣維護對映表的成本就會很大；
如果藉助雜湊演算法，這些問題都可以非常完美地解決。我們可以通過雜湊演算法，對客戶端 IP 地址或者會話 ID 計算雜湊值，將取得的雜湊值與伺服器列表的大小進行取模運算，最終得到的值就是應該被路由到的伺服器編號。 這樣，我們就可以把同一個 IP 過來的所有請求，都路由到同一個後端伺服器上。
應用六：資料分片
雜湊演算法還可以用於資料的分片。我這裡有兩個例子。
1. 如何統計“搜尋關鍵詞”出現的次數？
假如我們有 1T 的日誌檔案，這裡面記錄了使用者的搜尋關鍵詞，我們想要快速統計出每個關鍵詞被搜尋的次數，該怎麼做呢？
我們來分析一下。這個問題有兩個難點，第一個是搜尋日誌很大，沒辦法放到一臺機器的記憶體中。第二個難點是，如果只用一臺機器來處理這麼巨大的資料，處理時間會很長。
針對這兩個難點，我們可以先對資料進行分片，然後採用多臺機器處理的方法，來提高處理速度。具體的思路是這樣的：為了提高處理的速度，我們用 n 臺機器並行處理。我們從搜尋記錄的日誌檔案中，依次讀出每個搜尋關鍵詞，並且通過雜湊函式計算雜湊值，然後再跟 n 取模，最終得到的值，就是應該被分配到的機器編號。
這樣，雜湊值相同的搜尋關鍵詞就被分配到了同一個機器上。也就是說，同一個搜尋關鍵詞會被分配到同一個機器上。每個機器會分別計算關鍵詞出現的次數，最後合併起來就是最終的結果。
實際上，這裡的處理過程也是 MapReduce 的基本設計思想。
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 等資源的限制。
應用七：分散式儲存
現在網際網路面對的都是海量的資料、海量的使用者。我們為了提高資料的讀取、寫入能力，一般都採用分散式的方式來儲存資料，比如分散式快取。我們有海量的資料需要快取，所以一個快取機器肯定是不夠的。於是，我們就需要將資料分佈在多臺機器上。
該如何決定將哪個資料放到哪個機器上呢？我們可以借用前面資料分片的思想，即通過雜湊演算法對資料取雜湊值，然後對機器個數取模，這個最終值就是應該儲存的快取機器編號。
但是，如果資料增多，原來的 10 個機器已經無法承受了，我們就需要擴容了，比如擴到 11 個機器，這時候麻煩就來了。因為，這裡並不是簡單地加個機器就可以了。
原來的資料是通過與 10 來取模的。比如 13 這個資料，儲存在編號為 3 這臺機器上。但是新加了一臺機器中，我們對資料按照 11 取模，原來 13 這個資料就被分配到 2 號這臺機器上了。
因此，所有的資料都要重新計算雜湊值，然後重新搬移到正確的機器上。這樣就相當於，快取中的資料一下子就都失效了。所有的資料請求都會穿透快取，直接去請求資料庫。這樣就可能發生 雪崩效應 ，壓垮資料庫。
所以，我們需要一種方法，使得在新加入一個機器後，並不需要做大量的資料搬移。這時候，一致性雜湊演算法就要登場了。
假設我們有 k 個機器，資料的雜湊值的範圍是 [0, MAX]。我們將整個範圍劃分成 m 個小區間（m 遠大於 k），每個機器負責 m/k 個小區間。當有新機器加入的時候，我們就將某幾個小區間的資料，從原來的機器中搬移到新的機器中。這樣，既不用全部重新雜湊、搬移資料，也保持了各個機器上資料數量的均衡。
一致性雜湊演算法的基本思想就是這麼簡單。除此之外，它還會藉助一個虛擬的環和虛擬結點，更加優美地實現出來。這裡我就不展開講了，如果感興趣，你可以看下這個介紹： https://en.wikipedia.org/wiki/Consistent_hashing 。
除了我們上面講到的分散式快取，實際上，一致性雜湊演算法的應用非常廣泛，在很多分散式儲存系統中，都可以見到一致性雜湊演算法的影子。
解答開篇 & 內容小結
這兩節的內容理論不多，比較貼近具體的開發。今天我講了三種雜湊演算法在分散式系統中的應用，它們分別是：負載均衡、資料分片、分散式儲存。
在負載均衡應用中，利用雜湊演算法替代對映表，可以實現一個會話粘滯的負載均衡策略。在資料分片應用中，通過雜湊演算法對處理的海量資料進行分片，多機分散式處理，可以突破單機資源的限制。在分散式儲存應用中，利用一致性雜湊演算法，可以解決快取等分散式系統的擴容、縮容導致資料大量搬移的難題。