問題:有10 億個 url，每個 url 大小小於 56B，要求去重，內存只給你4G
思路：
1.首先將給定的url調用hash方法計算出對應的hash的value，在10億的url中相同url必然有着相同的value。
2.將文件的hash table 放到第value%n台機器上。
3.value/n是機器上hash table的值。
將文件分布在多個機器上，這樣要處理網路延時。假設有n台機器。
>>首先hash文件得到hash value v
>>將文件的hash table 放到第v%n 台機器上。
>>v/n是機器上hash table的值。
分析：
將文件的url進行hash，得到值value，相同的url的文件具有相同的value，所以會被分配到同一台機器v%n上。在同一台機器上的重復的url文件具有相同的value/n值，如果出現了沖突，不同的url在同一台機器上也可能有相同的value/n值。在每個機器上將value/n值作為key，url值作為value構成hash表進行去重。最后將內存中去重后的hash表中的value值即url寫入磁盤。合並磁盤中的各部分url文件，完成去重。
56byte;
4G =4*1024=4096kb=4096*1024 byte;
--------
轉自：https://www.cnblogs.com/aspirant/p/7154551.html
假如每個url大小為10bytes，那么可以估計每個文件的大小為50G×64=320G，遠遠大於內存限制的4G，所以不可能將其完全加載到內存中處理，可以采用分治的思想來解決。
Step1：遍歷文件a，對每個url求取hash(url)%1000，然后根據所取得的值將url分別存儲到1000個小文件(記為a0,a1,...,a999，每個小文件約300M);
Step2:遍歷文件b，采取和a相同的方式將url分別存儲到1000個小文件(記為b0,b1,...,b999);
巧妙之處：這樣處理后，所有可能相同的url都被保存在對應的小文件(a0vsb0,a1vsb1,...,a999vsb999)中，不對應的小文件不可能有相同的url。然后我們只要求出這個1000對小文件中相同的url即可。
Step3：求每對小文件ai和bi中相同的url時，可以把ai的url存儲到hash_set/hash_map中。然后遍歷bi的每個url，看其是否在剛才構建的hash_set中，如果是，那么就是共同的url，存到文件里面就可以了。
草圖如下(左邊分解A，右邊分解B，中間求解相同url)：
2.有一個1G大小的一個文件，里面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M，要求返回頻數最高的100個詞。
Step1：順序讀文件中，對於每個詞x，取hash(x)%5000，然后按照該值存到5000個小文件(記為f0,f1,...,f4999)中，這樣每個文件大概是200k左右，如果其中的有的文件超過了1M大小，還可以按照類似的方法繼續往下分，直到分解得到的小文件的大小都不超過1M;
Step2：對每個小文件，統計每個文件中出現的詞以及相應的頻率(可以采用trie樹/hash_map等)，並取出出現頻率最大的100個詞(可以用含100個結點的最小堆)，並把100詞及相應的頻率存入文件，這樣又得到了5000個文件;
Step3：把這5000個文件進行歸並(類似與歸並排序);
草圖如下(分割大問題，求解小問題，歸並)：
草圖如下(分割大問題，求解小問題，歸並)：
3.現有海量日志數據保存在一個超級大的文件中，該文件無法直接讀入內存，要求從中提取某天出訪問百度次數最多的那個IP。
Step1：從這一天的日志數據中把訪問百度的IP取出來，逐個寫入到一個大文件中;
Step2：注意到IP是32位的，最多有2^32個IP。同樣可以采用映射的方法，比如模1000，把整個大文件映射為1000個小文件;
Step3：找出每個小文中出現頻率最大的IP(可以采用hash_map進行頻率統計，然后再找出頻率最大的幾個)及相應的頻率;
Step4：在這1000個最大的IP中，找出那個頻率最大的IP，即為所求。
草圖如下：
