迅雷(XUNLEI)的工作原理揭密
迅雷(XUNLEI)如何搜索一個資源的多服務器版本？
-------實現一個類似迅雷的系統“福雷（FULEI）”
摘要：
當你用迅雷下載東西時，無論你是從迅雷資源頁點下載，還是從其它普通頁面點下載，你會發現它并不只用你的原始鏈接下載，它還搜索了一些其它服務器的相同資源，比起網絡螞蟻/網際快車之類的下載工具（這些都是純客戶端工具，而迅雷則有著服務器支持），大大增加成功下載的可能性和下載的速度，對比起P2P之類的下載軟件，又更干凈利落一些，那它是如何做到的呢？其實同baidu,google的基本原理是一樣的，只不過各自的技術又有側重而已，本文就個人經驗分析其實現渠道及基本原理，暫稱這個系統為福雷（FULEI），同本人名字有點諧音，呵呵，寫下此文，也不枉昨晚失眠的幾十分鐘。
搜索,視頻, 迅雷,p2p,下載,google,baidu,search,
?
轉載請注明出處及作者（http://blog.csdn.net/mudboy??? mudboy@csdn）
?
下載電影，音樂之類的大文件（相對于網頁）相信是每一個年輕人最愛干的一件事之一了，在這個P2P下載軟件橫行的時代，為什么像迅雷這樣的客戶/服務器模式還能有那么大市場呢？我曾試過好幾款P2P下載軟件（如電騾，天網MAZE等），但沒用多久就被我卸載了，我不喜歡被人家不斷讀硬盤的感覺，因為它們曾毀了我一塊硬盤，而且占了我太多的上行帶寬，個人認為，如果要用這類軟件，別裝在你的工作用機/學習用機上，而應專門用一臺破機器去運行它。使用迅雷還是一兩個月以前的事，因為在此之前，我主要還是用網際快車之類的軟件下載東西，這類軟件是純客戶端軟件，更多的無非是下載管理/斷點續傳/多線程下載之類的功能，下載速度基本上取決于資源鏈接服務器和網絡的速度，迅雷本身的客戶端功能同上述功能差不多，不同的只是它可以從迅雷自已的服務器中獲取其它服務器的相同資源信息，使單個資源可以從多個服務器/多線程/斷點續傳的下載，增加了資源成功下載的機率和速度，從我的使用過程看，很多資源的下載速度決不亞于P2P軟件，甚至還更快，但相對于P2P，人家不會從我的機器上下載內容，更不會占用我的上行帶寬，可以放心的在工作機上使用。
迅雷的這個點子，的確是個好點子！其實仔細想想，這其實只是個中庸的點子而已，介于P2P和純客戶端下載軟件（如NETANTS，FLASHGET之類）之間的一個中庸點子，由此又驗證了一句話：中庸在很多時候可能是最好的選擇。
我們的福雷要做同迅雷差不多的事，讀下文時可以暫將福字替換成迅。
談了這么多，還沒有談到一點技術性的內容，真唐僧！
福雷做法的關鍵在哪里？在于當用戶要下載一個資源時，如何去找在其它服務器上的完全相同的資源！
回顧一下普通搜索引擎的做法：用Crawler沒日沒夜的下載網頁，然后存儲，索引（倒排表是很常用的做法），用戶搜索時，它會根據索引找到符合的頁面，排序后，在本地服務器截取結果片段返回到客戶端。PDF/WORD等文檔的搜索也差不多，它們有個共同的特點是文件不太大，而且基本不太涉及版權問題，因而所有內容在自己服務器上都有快照。
但對于視頻/音頻等較大的文件（動則幾十兆上百兆到G級），如果按上述方式處理則會有一些問題，首先要爬完一個資源所消耗的代價太大，其次，即使下來了，也沒有太大的用處，你不能直接供用戶下載，這可能會遭遇訴訟，看看百度音樂搜索，以前搜出來的結果直接指向資源位置，現在還非得出一個對話框，將位置明示，生怕被人抓住把柄，個人認為完全沒有必要，也許是為了應付部分什么也不懂的官員，卻讓使用者感到不便。
既然是搜索，終歸需要先找到資源，這一點大家都一樣，基本的做法還是用Crawler，只不過，Crawler需要識別不同類型的資源區別對待，我們以視頻文件為例說明。
假如Crawler在工作的過程中標識出了所有視頻文件的鏈接并交于特殊的處理程序處理，接下來的問題如何存儲和索引這些信息，剛才已經說了，要下載整個視頻文件并不現實，而有一些內容是很容易得到的：資源鏈接，文件名/文件類型（擴展名），大小，存儲這些信息是簡單且必要的，
現在的關鍵問題是如何判斷文件的同價性？也就是說，如何知道這幾個文件是一樣的？存儲這個信息對我信至關重要，通過文件名？顯然不行，通過修改時間？作者？大小？等，都不太準確，最常用的方法還是計算文件摘要，而計算文件摘要最常用的方法又是MD5（雖說MD5可以破解，但對于大眾化應用，這種破解沒什么意義，而在非人為狀況下，MD5可以認為是可靠的），但這又出現一個新的難題，計算摘要需要所在文件內容，我們有以下選擇：
1、? 能不能在服務器上計算？（可惜視頻不像些開源軟件，下載鏈接中常有MD5摘要文件，這樣可以一并下來），而想在服務器上計算，是否有些異想天開？
2、? 下載所有內容計算摘要，上面已經說過這個問題
3、? 下載部分內容計劃摘要，聽起來真不錯，又是一個中庸的想法，我現在越來越喜歡中庸了，沒錯，就是它，但下載哪部分內容呢？我們可以根據文件大小利用一些簡單的散列算法生成散列值，根據這些值在文件的不同部分讀取一定量的數據，總數據量控制在K級別（同網頁差不多大小），然后將這些數據拼裝成整體存儲并生成其摘要。這種方法是可行的。首先，它的下載量不大，其次，根據該方法判文件的等價性同基準方法（根據所有數據算摘要）比準確率幾乎相同（證明過程我就不說了，實踐才是最好的標誰）
利用摘要判斷文件等價性的方法有一個好處是可以忽略一些次要信息，比如文件名，創建時間，修改時間等，但文件類型，長度和摘要則是需要考慮的成份。也就是說，如果這三者一樣，則我們認為文件是一樣的。
存儲完上述信息，至于如何索引，考慮的因素可能會多一些，最簡單的就以摘要索引就行，這樣等價資源會被聚類到一起，但作為一個資源聚集點，資源的描述信息也是要考慮進去的，等下我們會專門談到這個問題。
上面已經講完了主要內容，我們看看當我們利用福雷下載時它做了一些什么事情。
1、? 先看看普通的鏈接（非福雷鏈接）
a)???????? 用戶在任何一個網站想用其下載資源：http://blog.csdn.net/mudboy/movie/wanfang.rmvb
b)??????? 福雷客戶端將該連接發到福雷服務器，同時，客戶端也不閑著，它會去該鏈接獲取文件的基本信息（大小等），并按上面所述的算法下載部分內容并計算摘要。
c)??????? 服務端根據鏈接找自己服務器，看是否已被系統Crawler處理過，如果已被處理過，很簡單，通過其摘要找到所有含有該資源的服務器鏈接發到客戶端。
d)??????? 客戶端為了保險起見，會對比一下服務端的摘要和自己算出的摘要（避免文件在近期發生變動），如果一至，OK，可以從服務端發過來的多服務器下載了。
e)???????? 如果不一樣的話，客戶端需將該信息發到服務端，告訴它文件有變，服務端會去更新該文件的相關信息（包括等價文件鏈接），這個過程可以短也可能長，由此同時，客戶端會通過原始鏈接開始下載，服務端更新后，會陸續將確認后的鏈接發到客戶端，客戶端從而可又可從新增的鏈接下載。
f)???????? 接c)，如果服務端未找到原始鏈接呢？是不是意味著服務端就沒有其它鏈接呢？并不一定，此時，客戶端將信息及摘要發到服務端，服務端可根據摘要數據去搜索，如果搜索到結果，則將這些結果鏈接發到客戶端，并將該原始鏈接加入到服務器索引中，從而同樣實現多服務器下載，如果沒搜索到，則只能從原始鏈接下載資源了。
g)??????? 在上一步中，如果服務器沒找到原始鏈接也沒找到等價文件，服務端會存儲該并索引該鏈接信息。
h)??????? 在上述過程中，對于福雷服務器沒有的原始鏈接，用戶可以在門戶去發布該資源，此時，用戶就可以填入一些該資源的描述信息（這一步要都由公司人員去做，幾乎是不可能的），成千上萬的網民這樣做，門戶內容就豐富了（不僅有視頻，還有視頻的描述信息等其它一些元數據，前面提到索引方式，如果加上這部分內容的索引，又進一步實現在基于關鍵字的搜索）這本身又有點WEB2.0的概念，由網友自發來聚集和編輯視頻信息。
2、? 再看看專用鏈接，比如，你通過雷區找到的資源，有一些鏈接類似如下形式：
thunder://QUFmdHA6BDCsdi/ry+L1Byaxfdif=
對于這類鏈接，其實相當于一個映射而已，比如，在上一節的h)步驟中，用戶發布了一些資源，這個資源在福雷服務器中找到了一系列等價資源，這個搜索等價資源的過程是需要消耗服務器資源的（這個資源是指CPU/內存等機器資源），這樣，可以專為該資源生成一個URL，該URL就對應上述鏈接信息的索引以及用戶輸入的視頻元數據信息，這樣，用戶可以很容易通過關鍵字搜到該視頻，同時使用這類URL下載時，沒有一個搜索等價資源的過程，直接就可以返回一系列服務器鏈接到客戶端，直接實現多服務器下載。
?
說了這么多，本來應該畫個框架圖流程圖什么的，但愿說清楚了，有什么好的想法可以多交流。
?
總結
以上是生活随笔為你收集整理的迅雷(XUNLEI)的工作原理揭密的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 慎用AXIS2
- 下一篇： 慎用AXIS2(续)