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

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

　　對服務器的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 之后保存到哈希表中去重，相比于上面一種，能夠節約空間

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

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

　　分布式爬蟲架構

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

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

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

　　相關內容

　　java多線程的狀態轉換以及基本操作

　　常見Java多線程面試題總結

　　Java多線程學習,深入解析