一種互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)的制作方法
【專利摘要】本發(fā)明提供了一種互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)，該系統(tǒng)包括中心服務(wù)器、客戶端、下載服務(wù)器和運用事件觸發(fā)模型的DNS服務(wù)器集群。該系統(tǒng)能夠為搜索引擎的爬蟲提供高效、均衡的下載服務(wù)。
【專利說明】
一種互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)
技術(shù)領(lǐng)域
[0001]本發(fā)明涉及一種互聯(lián)網(wǎng)領(lǐng)域的系統(tǒng)，具體講涉及一種互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)?！颈尘凹夹g(shù)】
[0002]隨著互聯(lián)網(wǎng)的飛速發(fā)展，互聯(lián)網(wǎng)的數(shù)據(jù)越來越龐大，根據(jù)中國互聯(lián)網(wǎng)信息中心 2013年中國搜索引擎市場研究報告，目前中國注冊的網(wǎng)站數(shù)為320萬，域名數(shù)1844萬，網(wǎng)頁數(shù)為1500億，；截止2014年4月14日，全球總的域名已經(jīng)達到136, 285, 365,其中美國以 81，136, 981個域名居首位，中國擁有7, 907, 696個域名，位居第2。
[0003]搜索引擎作為獲取未知信息的主要方式，搜索引擎的爬蟲如何下載龐大的數(shù)據(jù)就是一個很重要的問題。傳統(tǒng)的單機下載模式，已經(jīng)無法很好的完成海量數(shù)據(jù)的下載任務(wù)，如何建立一個健壯的，高效的分布式下載系統(tǒng)，更顯得尤為重要。在實際情況之中，還有如下三個主要的問題:[〇〇〇4]1、分布式下載系統(tǒng)部署在機房時，由于機房自身的帶寬限制或者服務(wù)限制產(chǎn)生的問題。比如，下載機器還需提供其它的網(wǎng)絡(luò)服務(wù)，或整個機房還有其它的網(wǎng)絡(luò)服務(wù)，若下載系統(tǒng)全部占用下行的帶寬，會對集群的其它服務(wù)產(chǎn)生影響，造成這些服務(wù)訪問不正常；或， 一個下載系統(tǒng)有可能為多個其它系統(tǒng)提供下載服務(wù)，有的系統(tǒng)需要控制對對方網(wǎng)站的下載壓力，有的系統(tǒng)不能占據(jù)太多的下載帶寬。因此，如何有效并且簡單的控制整個下載系統(tǒng)的下載帶寬和均勻分配各個業(yè)務(wù)系統(tǒng)的下載請求到各個下載機器之上，也是十分必要和有實際意義的。
[0005]2、傳統(tǒng)的域名解析方法為通過操作系統(tǒng)自帶的gethostbyname底層c函數(shù)來進行域名解析，但由于該函數(shù)為同步函數(shù)，當(dāng)一個線程在等待域名解析時，其它線程調(diào)用此函數(shù)也將全被阻塞，因此，即使使用多線程的進行下載，在進行域名解析調(diào)用該函數(shù)，仍是全局阻塞，從而，當(dāng)遇到大量的域名解析請求時，域名解析成為整個下載系統(tǒng)的瓶頸。
[0006]雖然可以在各個下載程序內(nèi)緩存部分DNS解析的結(jié)果，在下一次同域名解析時直接從緩存中獲取，但此類方案也存在缺點。一、每一個下載端都需存儲一份數(shù)據(jù)；二、域名總數(shù)十分龐大，全球已有1.3億，其中還包括已經(jīng)失效或故意作弊的域名，實際情況遠遠大于 1.3億；另外，域名解析支持通配解析，比如，*.qzone.qq.com，*可為任何QQ號碼，它們一般指向同一個IP，但DNS解析過程無法得知這一條解析規(guī)則，也無法存儲這一條規(guī)則，這條規(guī)則是對方DNS解析服務(wù)器的解析規(guī)則，因此，只能針對于每一個QQ號碼的域名，存儲一個鍵值對，即域名/IP對，那么僅僅這一條通配符規(guī)則所產(chǎn)生的域名就是海量的，從而，在每一個下載程序內(nèi)部緩存全部的DNS解析結(jié)果，是不可行的。由此可見，DNS解析是廣域網(wǎng)爬蟲一個技術(shù)難點和關(guān)鍵點。
[0007]3、由于互聯(lián)網(wǎng)各個服務(wù)器的位置和服務(wù)器帶寬的能力的大小，在進行下載網(wǎng)頁時，I/O等待造成的URL的延時的不同，也會影響整個系統(tǒng)的下載速度和能力，而傳統(tǒng)解決 10等待的方案就是多線程模型，即各個線程完成不同的下載任務(wù)，互不影響，但使用多線程模型的缺陷就是若要提高單臺機器的下載能力，就必須開更多的線程，而線程的開銷也非常大，無論是內(nèi)存或者CPU的調(diào)度都會給下載機器很大的壓力。因此，多線程用于海量數(shù)據(jù)下載并不是一個最優(yōu)的方案，而需要使用更高效的網(wǎng)絡(luò)通信模型。
[0008]因此，提供一個能解決海量數(shù)據(jù)所引發(fā)的技術(shù)細節(jié)，更好完成下載服務(wù)，也才能為搜索引擎提供數(shù)據(jù)支持的高效和健壯的下載系統(tǒng)尤為重要。
【發(fā)明內(nèi)容】

[0009]為克服上述現(xiàn)有技術(shù)的不足，本發(fā)明提供一種互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)。
[0010]實現(xiàn)上述目的所采用的解決方案為:
[0011]—種互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)，其改進之處在于:所述系統(tǒng)包括中心服務(wù)器、 客戶端、下載服務(wù)器和運用事件觸發(fā)模型的DNS服務(wù)器集群。
[0012]進一步的，所述中心服務(wù)器實現(xiàn)所述下載服務(wù)器的下載調(diào)度，所述下載服務(wù)器完成下載任務(wù)；所述下載服務(wù)器周期性向所述中心服務(wù)器發(fā)送heartbeat和下載狀態(tài)；
[0013]所述客戶端向所述中心服務(wù)器發(fā)送下載請求，所述中心服務(wù)器根據(jù)所述下載服務(wù)器運行情況和下載服務(wù)類別的下載數(shù)量配額向所述客戶端返回指令。
[0014]進一步的，所述返回指令包括以下情況:
[0015]若存在下載資源，則向所述客戶端返回下載流水ID和下載服務(wù)器的IP ;所述客戶端向所述下載服務(wù)器發(fā)送所述下載流水ID和下載URL，所述下載服務(wù)器向所述中心服務(wù)器驗證下載所述下載流水ID和下載URL是否有效，有效則進入預(yù)備下載隊列，等待下載；所述下載服務(wù)器完成一條URL的下載后，將下載結(jié)果發(fā)送至所述客戶端的接收端口，完成下載；
[0016]若不存在下載資源，則向所述下載服務(wù)器返回拒絕信號，所述下載服務(wù)器接收所述拒絕信號，等待一段時間再向所述中心服務(wù)器發(fā)送另一個下載請求。
[0017]進一步的，所述中心服務(wù)器啟動時裝載下載配額列表，所述下載配額列表包括多條數(shù)據(jù)，所述數(shù)據(jù)包含下載服務(wù)名和每一秒的下載配置數(shù)。
[0018]進一步的，所述中心服務(wù)器根據(jù)分布式系統(tǒng)的下載服務(wù)器運行情況和下載服務(wù)類別的下載數(shù)量配額向所述客戶端返回指令包括以下步驟:
[0019]1、獲取所述下載服務(wù)名每秒的配額數(shù)，若所述下載配額表之中不存在該服務(wù)名， 返回no ;
[0020]I1、若存在此服務(wù)名，獲取系統(tǒng)當(dāng)前分鐘的當(dāng)前秒數(shù)s、每一秒的配額數(shù)m、該服務(wù)這一分鐘內(nèi)已分配的下載數(shù)據(jù)n，若t+n>s*m，t為客戶端下載的URL的數(shù)目，返回no,否則進入步驟III ;
[0021]c、遍歷所有上報心跳數(shù)的下載服務(wù)器，如下式確定所述下載服務(wù)器剩余的槽數(shù)的預(yù)計值u，u = p*s+q_r，其中，p為各個下載服務(wù)器上一次上報心跳的平均下載速度p，q為剩余槽數(shù)，r為這一分鐘已經(jīng)給此下載服務(wù)器分配的下載任務(wù)數(shù)；
[0022]若u>t，將所述下載服務(wù)器放入備選機器列表，待遍歷整個下載服務(wù)器列表之后， 若備選下載服務(wù)器列表為空，返回no,若存在多個備選下載服務(wù)器，選取u值最大的下載服務(wù)器，并賦值n = n+t，r = r+t，返回此機器IP和yes ;
[0023]IV、每一分鐘的1秒，中心服務(wù)器將遍歷整個下載系統(tǒng)的各個下載服務(wù)，將已分配的URL數(shù)n清零，另外，遍歷所有下載下載服務(wù)器列表，將每一個下載服務(wù)器的已分配的下載數(shù)目r清零，從而，當(dāng)一個下一分鐘開始時，整個下載系統(tǒng)恢復(fù)初始狀態(tài)。
[0024]進一步的，所述DNS服務(wù)器集群使用事件觸發(fā)模式進行下載，利用Libcares進行異步的DNS解析，提高下載速度。
[0025]進一步的，所述DNS服務(wù)器集群包括底層DNS server、上層DNS server和外網(wǎng)DNS server〇
[0026]進一步的，所述下載服務(wù)器進行域名解析，向所述底層DNS server發(fā)送請求，若底層DNS查詢不為空，貝lj底層DNS server返回，否則向上層DNS server發(fā)送請求；
[0027]若上層DNS server查詢不為空，貝lj所述上層DNS server返回，否則向外網(wǎng)DNS server發(fā)送請求，夕卜網(wǎng)DNS返回；
[0028]與對方服務(wù)器建立連接，發(fā)送下載請求，對方服務(wù)器響應(yīng)，返回下載結(jié)果給所述下載服務(wù)器。
[0029]與現(xiàn)有技術(shù)相比，本發(fā)明具有以下有益效果:
[0030]1、本發(fā)明的系統(tǒng)解決了采用輕中心化的分布式模型，下載帶寬控制，DNS解析系統(tǒng) 3個策略來解決現(xiàn)有分布式下載系統(tǒng)的問題由于中心化的服務(wù)器負載過重，整個集群的下載帶寬控制，以及域名解析和下載通信模型的幾個問題，該系統(tǒng)能夠提供高效、均衡的下載服務(wù)。
[0031]2、本發(fā)明的系統(tǒng)的中心服務(wù)器的負責(zé)調(diào)度下載帶寬，壓力很小，Slave與Master 之間保持嚴格的C/S模型，客戶端直接Slave通信，減少了網(wǎng)絡(luò)傳輸。
[0032]3、本發(fā)明的系統(tǒng)保證了下載集群下載帶度的使用率，并且不會影響其它的網(wǎng)絡(luò)服務(wù)。
[0033]4、本發(fā)明的系統(tǒng)采用DNS解析系統(tǒng)和異步DNS解析，很好的解決了互聯(lián)網(wǎng)大批量的DNS解析的問題；用于DNS解析的DNS集群服務(wù)器采用分層架構(gòu)，既保證DNS解析速度， 又不會對外網(wǎng)DNS服務(wù)器造成巨大的壓力。
[0034]5、本發(fā)明的系統(tǒng)使用事件觸發(fā)模式進行下載，減少了多線程模式的系統(tǒng)資源使用率，并且提高了下載速度。
[0035]6、本發(fā)明的系統(tǒng)采用主從模式下載服務(wù)集群，中心服務(wù)器Master是一個輕量級的服務(wù)，不負責(zé)具體的下載，但是負責(zé)整個下載集群的流量控制，使下載集群的帶寬使用能保持一個平穩(wěn)的使用率，既不出現(xiàn)高的峰谷，使下載占用機房的所有下行帶寬，也不會出現(xiàn)波谷，使機房的下行帶寬沒有充分利用。通過一個很輕量級的服務(wù)，控制了整個下載系統(tǒng)的均衡性?！靖綀D說明】
[0036]圖1為本實施例中互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)示意圖?！揪唧w實施方式】
[0037]下面結(jié)合附圖對本發(fā)明的【具體實施方式】做進一步的詳細說明。
[0038]本發(fā)明提供了互聯(lián)網(wǎng)爬蟲的分布式系統(tǒng)的下載系統(tǒng)包括一個中心服務(wù)器 (Master)、若干個下載服務(wù)器(Slave)、需要下載資源的客戶端(Client)和運用事件觸發(fā)模型的DNS服務(wù)器集群。
[0039]中心服務(wù)器(Master)，實現(xiàn)下載服務(wù)器的下載調(diào)度，不負責(zé)下載任務(wù)；
[0040]下載服務(wù)器(Slave)，完成具體的下載任務(wù)，下載服務(wù)器周期性向中心服務(wù)器發(fā)送心跳(Heartbeat，表示網(wǎng)絡(luò)中的節(jié)點及確認其正常工作)和下載狀態(tài)；通過心跳和心跳的附屬信息，確認下載服務(wù)器仍正常，防止客戶端將一要下載的url發(fā)送給一個已經(jīng)當(dāng)機的 slave〇
[0041]上述下載狀態(tài)包括下載成功數(shù)、失敗數(shù)、速率、目前此下載服務(wù)器可用的下載空閑的槽數(shù)等。
[0042]客戶端(Client)，一個需要下載資源的程序，向所述中心服務(wù)器發(fā)送下載請求，中心服務(wù)器根據(jù)分布式系統(tǒng)的下載服務(wù)器運行情況和下載服務(wù)類別的下載數(shù)量配額向所述客戶端返回指令。
[0043]中心服務(wù)器(Master)在接受下載服務(wù)器(Slave)的狀態(tài)報告之后，更新自己的內(nèi)存下載服務(wù)器(Slave)下載服務(wù)的狀態(tài)。中心服務(wù)器(Master)與下載服務(wù)器(Slave) 之間遵守嚴格的Server/Client模型，中心服務(wù)器(Master)不主動向下載服務(wù)器(Slave) 發(fā)送請求，下載服務(wù)器(Slave)向中心服務(wù)器(Master)主動上報心跳，若某個下載服務(wù)器(Slave)在2個周期之內(nèi)沒有上報心跳，那么中心服務(wù)器(Master)在接受到客戶端 (Client)的下載要求之后，將此下載服務(wù)器(Slave)排除在外，客戶端(Client)不會向一個已死的下載服務(wù)器(Slave)發(fā)送下載URL。
[0044]DNS服務(wù)器集群，使用事件觸發(fā)模式進行下載，利用Libcares進行異步的DNS解析，提高下載速度。
[0045]事件觸發(fā)模型(或稱事件驅(qū)動模型，event-driven)，為一種網(wǎng)絡(luò)通信方式，代表是linux之下的epoll與windows之下的完成端口。本發(fā)明中，實際使用的是包裝epoll的 libevent，本質(zhì)為用一個線程去監(jiān)聽很多的網(wǎng)絡(luò)套接字(socket)，并且由底層硬件驅(qū)動， 從而提高讀與寫的速度，且由于以上操作為單線程操作，所用cpu與內(nèi)存資源都較少。相比于傳統(tǒng)的多線程下載模型來說，若要并發(fā)下載2000個網(wǎng)頁需開啟2000個線程，而2000個線程對于操作的cpu與內(nèi)存是一個極大的開銷。本發(fā)明的系統(tǒng)采用事件驅(qū)動模式，只需一個線程去監(jiān)聽2000個套接字即可。最大占用一個cpu，沒有多作的線程開銷，并且讀寫速度也更快。
[0046]事件驅(qū)動的通信應(yīng)用在兩個方面:DNS集群之間的通信和slave下載具體網(wǎng)頁的與對方服務(wù)器的通信。
[0047]如圖1所示，圖1為本實施例中互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)示意圖；本實施例的下載系統(tǒng)包括:一個中心服務(wù)器(Master)、兩個下載服務(wù)器(Slave) Slave 1和Slave2、客服端(Client)和DNS服務(wù)器集群。
[0048]下載服務(wù)器Slavel與Slave2是對等關(guān)系，均需完成發(fā)送心跳和接受下載任務(wù)。向中心服務(wù)器(Master)發(fā)出下載的請求，提供需要批量下載的URL數(shù)量和此類下載服務(wù)的名稱，中心服務(wù)器(Master)根據(jù)目前整下載系統(tǒng)下載服務(wù)器(Slave)運行情況和具體的下載服務(wù)類別的下載數(shù)量配額完成下載調(diào)度，對于客戶端的請求做出回應(yīng)，包括兩種情況，本實施例中認為Slave2為最合適的Slave，以此為例具體說明:
[0049](A)、如果目前有下載資源，則向Client返回一個下載流水ID及Slave的IP，上述下載流水ID為一個遞增的數(shù)字ID，用于防止重復(fù)下載，Slave的IP是一個最合適的下載Slave的IP ;Client在接受這個下載流水ID和Slave的IP后，向此IP的Slave發(fā)送相應(yīng)的下載流水ID及需要下載的這一批URL，Slave接受此下載流水ID以及這一批URL，向 Master進行驗證這個下載流水ID是否有效(也可以省略此步驗證)，再將這一批URL放入自已的預(yù)備下載隊列，等待下載，當(dāng)Slave完成某一條URL的下載之后，將下載結(jié)果發(fā)送給客戶端Client的接收端口，完成下載。
[0050](B)、如果目前沒有下載資源，如:目前沒有可以提供下載的Slave或此類下載服務(wù)已經(jīng)達到下載配額等情況，則向Client返回no, Client授受到no的消息之后，等待一段時間，再重新向Master發(fā)送另一個下載請求。
[0051]以上過程中，本實施例的Master在接受Slave的狀態(tài)報告之后，更新自己的內(nèi)存 Slave下載服務(wù)的狀態(tài)。Master與Slave之間遵守嚴格的Server/Client模型，Master不主動向Slave發(fā)送請求，Slave向Master主動上報心跳，若某個Slave在2個周期之內(nèi)沒有上報心跳，Master在接受到Client的下載要求之后，將此Slave排除在外，Client不會向一個已死的Slave發(fā)送下載URL。
[0052]本實施例中，若存在多個備選下載服務(wù)器，選取Slave剩余的槽數(shù)的預(yù)計值u值最大的下載服務(wù)器，認為該選擇為最合適的下載服務(wù)器slave，選一個最空閑的slave。
[0053]本實施例中，中心服務(wù)器(Master)進行流量控制和下載資源分配，Master在啟動時裝載一個下載配額列表，此列表包括多條數(shù)據(jù)，一條數(shù)據(jù)包含一個下載服務(wù)名和每一秒的下載配置數(shù)。在接受到一個Client下載請求時，Client需要上報自已下載服務(wù)的名和下載的URL的數(shù)目t，Master在接受到這個請求之后，完成如下邏輯，實現(xiàn)根據(jù)分布式系統(tǒng)的下載服務(wù)器運行情況和下載服務(wù)類別的下載數(shù)量配額向客戶端返回指令:
[0054]1、獲取下載服務(wù)名每秒的配額數(shù)，若下載配額表之中沒有此服務(wù)名，直接返回no。
[0055]I1、如果此服務(wù)名存在，獲取系統(tǒng)當(dāng)前分鐘的當(dāng)前秒數(shù)s、每一秒的配額數(shù)m、此服務(wù)這一分鐘之內(nèi)已分配的下載數(shù)據(jù)n，如果t+n>s*m，代表配額已經(jīng)分配完，返回no,否則進入步驟III ;
[0056]II1、如果t+n〈s*m，表示這一分鐘累計的下載配額仍然有剩余，遍歷所有上報心跳數(shù)的Slave，根據(jù)各個Slave上一次上報心跳的平均下載速度設(shè)為p、Slave剩余的槽數(shù)q、 這一分鐘已經(jīng)給此Slave分配的下載任務(wù)數(shù)r，如下式計算這個Slave剩余的槽數(shù)的預(yù)計值 u:
[0057]u = p*s+q_r ;
[0058]比較u和t，若u>t，將此Slave放入備選機器列表，待遍歷整個Slave列表之后， 若備選機器列表為空，返回no,若有多個備選機器，從列表選取一個u最大的Slave機器，并進行賦值n = n+t，r = r+t，返回此機器IP和yes。
[0059]IV、每一分鐘的第1秒，Master將遍歷整個下載系統(tǒng)的各個下載服務(wù)，將已分配的 URL數(shù)n清零，遍歷所有下載slave機器列表，將每一個Slave的已分配的下載數(shù)目r清零， 從而，當(dāng)一個下一分鐘開始時，整個下載系統(tǒng)恢復(fù)初始狀態(tài)。
[0060]以上步驟解決整個下載系統(tǒng)中整個集群的下載帶寬控制和各個下載系統(tǒng)下載配額的問題，且各個下載服務(wù)器Slave之間互不影響。
[0061]以上方法通過控制每一秒的URL分配數(shù)目，而每一秒沒使用的下載配額，只在這一分鐘之內(nèi)有效，因此，基本上每一秒整個下載集群之上并發(fā)下載的URL數(shù)目是一定的，從而下載所占的帶寬也是一定的，且?guī)捳加们€不會出現(xiàn)很大的波峰和波谷，從整個防火墻的網(wǎng)絡(luò)占用率圖形上來看，基本上是一條平行的直線。
[0062]DNS解析廣域網(wǎng)下載爬蟲的關(guān)鍵?，F(xiàn)有的解析方法為:操作系統(tǒng)自帶的 gethostbyname函數(shù)，此函數(shù)是一個同步的全局阻塞函數(shù)，為了加速下載，不能使用此函數(shù)進行域名解析，而要使用異步域名解析函數(shù)。另外，多線程在進行下載時并不能很好的提高并發(fā)，如果需要200并發(fā)，就要開啟200線程，這樣的下載模型對下載機器的cpu和內(nèi)存都造成巨大的壓力，因此，為了提高并發(fā)，需要使用事件觸發(fā)模型，此模型只需要一個線程，操作系統(tǒng)完成套接字的可讀和可寫的觸發(fā)，從而大大減輕Slave下載服務(wù)器的CPU和內(nèi)存的壓力。
[0063]本實施例中的DNS服務(wù)器集群運用事件觸發(fā)模型進行下載，并利用Libcares進行異步DNS解析。通過事件觸發(fā)模型和異步DNS解析，大大提高下載速度。
[0064]考慮DNS解析是一個非常耗時和復(fù)雜的請求，一次DNS請求需要遞歸查找，且各域名解析之后的結(jié)果記錄有不同的生存周期，而生存周期是由于對方DNS服務(wù)器設(shè)置，有的非常短，幾個小時，有的非常長，幾個月也有可能。一般情況之下，生存周期非常短的DNS并不會在幾個小時之內(nèi)更改域名解析的IP，而非常長的生存周期的記錄有時卻會造成IP已經(jīng)失效的問題。因此當(dāng)搭建DNS解析系統(tǒng)之后，就可控制DNS記錄的生成周期，將生存周期的短DNS記錄加長，來減少重復(fù)的DNS查詢次數(shù)，將生存周期長的DNS記錄變短，減少DNS失效的情況。另外，對于大規(guī)模的下載程序來說，單臺DNS解析服務(wù)器也會成瓶頸，從而必須使用DNS解析集群，Libcares支持多臺DNS服務(wù)器進行輪流查找，但如果這些內(nèi)部DNS服務(wù)器全部向外網(wǎng)的某臺DNS服務(wù)器進行請求，就會造成對外網(wǎng)的DNS服務(wù)器壓力過大，且內(nèi)部的DNS服務(wù)器存儲的數(shù)據(jù)基本上是相同的；因此DNS服務(wù)器需要使用層狀結(jié)構(gòu)，使用一臺的 DNS服務(wù)器向外界DNS發(fā)送請求，而其它的內(nèi)部DNS服務(wù)器向這臺DNS服務(wù)器發(fā)送請求，從而DNS解析是一個遞歸的過程，以上方案對于Libcares完全透明，能夠很好的解決DNS數(shù)據(jù)共享的問題。
[0065]本實施例中，DNS服務(wù)器集群包括底層DNS服務(wù)器(底層DNS server)、上層DNS 服務(wù)器(上層DNS server)和外網(wǎng)DNS服務(wù)器(外網(wǎng)DNS server) 〇
[0066]底層DNS服務(wù)器負責(zé)為Slave提供DNS查詢服務(wù)，若底層DNS服務(wù)器不包含某個查詢的結(jié)果，向上層DNS服務(wù)器發(fā)送請求，反之，直接返回給Slave內(nèi)存的結(jié)果。上層DNS服務(wù)器在接受到底層DNS服務(wù)器之后，如果內(nèi)存中有相應(yīng)的記錄，直接返回，反之，向外網(wǎng)DNS 服務(wù)器發(fā)送請求。
[0067]只有一個上層DNS服務(wù)器向外網(wǎng)發(fā)送請求，從而減輕對外網(wǎng)DNS服務(wù)器的壓力。 且，上層DNS服務(wù)器為底層的DNS服務(wù)器提供一級緩存機制。
[0068]本實施例中，DNS服務(wù)器集群的操作過程如下:
[0069]下載服務(wù)器進行域名解析，向底層DNS服務(wù)器發(fā)送請求，若底層DNS查詢不為空， 則底層DNS server返回，否則向上層DNS server發(fā)送請求；
[0070]若上層DNS server查詢不為空，則上層DNS server返回，否則向外網(wǎng)DNS server 發(fā)送請求，外網(wǎng)DNS返回；
[0071]與對方服務(wù)器建立連接，發(fā)送下載請求，對方服務(wù)器響應(yīng)，返回下載結(jié)果給所述下載服務(wù)器。
[0072] 最后應(yīng)當(dāng)說明的是:以上實施例僅用于說明本申請的技術(shù)方案而非對其保護范圍的限制，盡管參照上述實施例對本申請進行了詳細的說明，所屬領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解:本領(lǐng)域技術(shù)人員閱讀本申請后依然可對申請的【具體實施方式】進行種種變更、修改或者等同替換，但這些變更、修改或者等同替換，均在申請待批的權(quán)利要求保護范圍之內(nèi)。
【主權(quán)項】
1.一種互聯(lián)網(wǎng)爬蟲的分布式下載系統(tǒng)，其特征在于:所述系統(tǒng)包括中心服務(wù)器、客戶 端、下載服務(wù)器和運用事件觸發(fā)模型的DNS服務(wù)器集群。2.如權(quán)利要求1所述的系統(tǒng)，其特征在于:所述中心服務(wù)器實現(xiàn)所述下載服務(wù)器的 下載調(diào)度，所述下載服務(wù)器完成下載任務(wù)；所述下載服務(wù)器周期性向所述中心服務(wù)器發(fā)送 heartbeat和下載狀態(tài)；所述客戶端向所述中心服務(wù)器發(fā)送下載請求，所述中心服務(wù)器根據(jù)所述下載服務(wù)器運 行情況和下載服務(wù)類別的下載數(shù)量配額向所述客戶端返回指令。3.如權(quán)利要求2所述的系統(tǒng)，其特征在于:所述返回指令包括以下情況:若存在下載資源，則向所述客戶端返回下載流水ID和下載服務(wù)器的IP ;所述客戶端向 所述下載服務(wù)器發(fā)送所述下載流水ID和下載URL，所述下載服務(wù)器向所述中心服務(wù)器驗證 下載所述下載流水ID和下載URL是否有效，有效則進入預(yù)備下載隊列，等待下載；所述下載 服務(wù)器完成一條URL的下載后，將下載結(jié)果發(fā)送至所述客戶端的接收端口，完成下載；若不存在下載資源，則向所述下載服務(wù)器返回拒絕信號，所述下載服務(wù)器接收所述拒 絕信號，等待一段時間再向所述中心服務(wù)器發(fā)送另一個下載請求。4.如權(quán)利要求1所述的系統(tǒng)，其特征在于:所述中心服務(wù)器啟動時裝載下載配額列表， 所述下載配額列表包括多條數(shù)據(jù)，所述數(shù)據(jù)包含下載服務(wù)名和每一秒的下載配置數(shù)。5.如權(quán)利要求2所述的系統(tǒng)，其特征在于:所述中心服務(wù)器根據(jù)分布式系統(tǒng)的下載服 務(wù)器運行情況和下載服務(wù)類別的下載數(shù)量配額向所述客戶端返回指令包括以下步驟:1、獲取所述下載服務(wù)名每秒的配額數(shù)，若所述下載配額表之中不存在該服務(wù)名，返回no ；I1、若存在此服務(wù)名，獲取系統(tǒng)當(dāng)前分鐘的當(dāng)前秒數(shù)s、每一秒的配額數(shù)m、該服務(wù)這一 分鐘內(nèi)已分配的下載數(shù)據(jù)n，若t+n>s*m，t為客戶端下載的URL的數(shù)目，返回no,否則進入 步驟III ;II1、遍歷所有上報心跳數(shù)的下載服務(wù)器，如下式確定所述下載服務(wù)器剩余的槽數(shù)的預(yù) 計值u，u = p*s+q_r，其中，p為各個下載服務(wù)器上一次上報心跳的平均下載速度p，q為剩 余槽數(shù)，r為這一分鐘已經(jīng)給此下載服務(wù)器分配的下載任務(wù)數(shù)；若u>t，將所述下載服務(wù)器放入備選機器列表，待遍歷整個下載服務(wù)器列表之后，若備 選下載服務(wù)器列表為空，返回no,若存在多個備選下載服務(wù)器，選取u值最大的下載服務(wù) 器，并賦值n = n+t，r = r+t，返回此機器IP和yes ;IV、每一分鐘的1秒，中心服務(wù)器將遍歷整個下載系統(tǒng)的各個下載服務(wù)，將已分配的 URL數(shù)n清零，另外，遍歷所有下載服務(wù)器列表，將每一個下載服務(wù)器的已分配的下載數(shù)目 r清零，從而，當(dāng)一個下一分鐘開始時，整個下載系統(tǒng)恢復(fù)初始狀態(tài)。6.如權(quán)利要求1所述的系統(tǒng)，其特征在于:所述DNS服務(wù)器集群使用事件觸發(fā)模式進 行下載，利用Libcares進行異步的DNS解析，提高下載速度。7.如權(quán)利要求1所述的系統(tǒng)，其特征在于:所述DNS服務(wù)器集群包括底層DNS server、 上層 DNS server 和外網(wǎng) DNS server。8.如權(quán)利要求7所述的系統(tǒng)，其特征在于:所述下載服務(wù)器進行域名解析，向所述底層 DNS server發(fā)送請求，若底層DNS查詢不為空，則底層DNS server返回，否則向上層DNS server發(fā)送請求；若上層DNS server查詢不為空，貝ij所述上層DNS server返回，否則向外網(wǎng)DNS server 發(fā)送請求，外網(wǎng)DNS返回；與對方服務(wù)器建立連接，發(fā)送下載請求，對方服務(wù)器響應(yīng)，返回下載結(jié)果給所述下載服 務(wù)器。
【文檔編號】H04L29/12GK105991699SQ201510063839
【公開日】2016年10月5日
【申請日】2015年2月6日
【發(fā)明人】席齊, 許歡慶, 郭永福, 陳沛
【申請人】北京中搜網(wǎng)絡(luò)技術(shù)股份有限公司