在我們調試爬蟲程序的時候，單線程爬蟲沒什么問題，但是當我們在線上環境使用單線程爬蟲程序去采集網頁時，單線程就暴露出了兩個致命的問題：

采集效率特別慢，單線程之間都是串行的，下一個執行動作需要等上一個執行完才能執行

對服務器的CUP等利用率不高，想想我們的服務器都是8核16G，32G的只跑一個線程會不會太浪費啦

線上環境不可能像我們本地測試一樣，不在乎采集效率，只要能正確提取結果就行。在這個時間就是金錢的年代，不可能給你時間去慢慢的采集，所以單線程爬蟲程序是行不通的，我們需要將單線程改成多線程的模式，來提升采集效率和提高計算機利用率。

多線程的爬蟲程序設計比單線程就要復雜很多，但是與其他業務在高并發下要保證數據安全又不同，多線程爬蟲在數據安全上到要求不是那么的高，因為每個頁面都可以被看作是一個獨立體。要做好多線程爬蟲就必須做好兩點：第一點就是統一的待采集URL維護，第二點就是URL的去重，下面我們簡單的來聊一聊這兩點。

維護待采集的URL

多線程爬蟲程序就不能像單線程那樣，每個線程獨自維護這自己的待采集URL，如果這樣的話，那么每個線程采集的網頁將是一樣的，你這就不是多線程采集啦，你這是將一個頁面采集的多次。基于這個原因我們就需要將待采集的URL統一維護，每個線程從統一URL維護處領取采集URL，完成采集任務，如果在頁面上發現新的URL鏈接則添加到統一URL維護的容器中。下面是幾種適合用作統一URL維護的容器：

JDK的安全隊列，例如LinkedBlockingQueue

高性能的NoSQL，比如Redis、Mongodb

MQ消息中間件

URL的去重

URL的去重也是多線程采集的關鍵一步，因為如果不去重的話，那么我們將采集到大量重復的URL，這樣并沒有提升我們的采集效率，比如一個分頁的新聞列表，我們在采集第一頁的時候可以得到2、3、4、5頁的鏈接，在采集第二頁的時候又會得到1、3、4、5頁的鏈接，待采集的URL隊列中將存在大量的列表頁鏈接，這樣就會重復采集甚至進入到一個死循環當中，所以就需要URL去重。URL去重的方法就非常多啦，下面是幾種常用的URL去重方式：

將URL保存到數據庫進行去重，比如redis、MongoDB

將URL放到哈希表中去重，例如hashset

將URL經過MD5之后保存到哈希表中去重，相比于上面一種，能夠節約空間

使用布隆過濾器(BloomFilter)去重，這種方式能夠節約大量的空間，就是不那么準確。

關于多線程爬蟲的兩個核心知識點我們都知道啦，下面我畫了一個簡單的多線程爬蟲架構圖，如下圖所示：

上面我們主要了解了多線程爬蟲的架構設計，接下來我們不妨來試試Java多線程爬蟲，我們以采集虎撲新聞為例來實戰一下Java多線程爬蟲，Java多線程爬蟲中設計到了待采集URL的維護和URL去重，由于我們這里只是演示，所以我們就使用JDK內置的容器來完成，我們使用LinkedBlockingQueue作為待采集URL維護容器，HashSet作為URL去重容器。下面是Java多線程爬蟲核心代碼，詳細代碼以上傳GitHub，地址在文末：

我們用5個線程去采集虎撲新聞列表頁看看效果如果？運行該程序，得到如下結果：

結果中可以看出，我們啟動了5個線程采集了61頁頁面，一共耗時2秒鐘，可以說效果還是不錯的，我們來跟單線程對比一下，看看差距有多大？我們將線程數設置為1，再次啟動程序，得到如下結果：

可以看出單線程采集虎撲61條新聞花費了7秒鐘，耗時差不多是多線程的4倍，你想想這可只是61個頁面，頁面更多的話，差距會越來越大，所以多線程爬蟲效率還是非常高的。

分布式爬蟲架構

分布式爬蟲架構是一個大型采集程序才需要使用的架構，一般情況下使用單機多線程就可以解決業務需求，反正我是沒有分布式爬蟲項目的經驗，所以這一塊我也沒什么可以講的，但是我們作為技術人員，我們需要對技術保存熱度，雖然不用，但是了解了解也無妨，我查閱了不少資料得出了如下結論：

分布式爬蟲架構跟我們多線程爬蟲架構在思路上來說是一樣的，我們只需要在多線程的基礎上稍加改進就可以變成一個簡單的分布式爬蟲架構。因為分布式爬蟲架構中爬蟲程序部署在不同的機器上，所以我們待采集的URL和采集過的URL就不能存放在爬蟲程序機器的內存中啦，我們需要將它統一在某臺機器上維護啦，比如存放在Redis或者MongoDB中，每臺機器都從這上面獲取采集鏈接，而不是從LinkedBlockingQueue這樣的內存隊列中取鏈接啦，這樣一個簡單的分布式爬蟲架構就出現了，當然這里面還會有很多細節問題，因為我沒有分布式架構的經驗

以上就是動力節點java培訓機構的小編針對“Java爬蟲教程，多線程爬蟲及分布式爬蟲”的內容進行的回答，希望對大家有所幫助，如有疑問，請在線咨詢，有專業老師隨時為你服務。