爬蟲具體問題

1，如何模擬登錄
2，驗證碼識別
3，分佈式爬取網頁
4，數據存儲
5，網頁更新
6，基於關鍵字的微博爬取

而後上面的每個問題其實研究起來都是頗有意思的。雖然上面的每個問題都有不少人解決，可是我感受都不是很漂亮，下面一點一點來分析：
第一個，模擬登錄。我估計啊，每個爬微博數據的人都會花費50%的時間在這，這仍是保守估計。我說的模擬登錄不只僅只是登錄成功就ok了，還有不少問題須要解決，好比一下幾個小問題：

（1）登錄成功之後如何保存cookie，方便下一次發起請求的時候直接放入請求頭裏面(注意這裏是分佈式的爬蟲，因此cookie存儲要考慮分佈式的環境)
（2）如何檢測cookie的失效時間，以便你從新登陸，刷新cookie
（3）發起請求後，對狀態碼的處理，經過狀態碼的分析，去檢測是否是帳號的問題。你好比微博發生302重定向，那極可能就是帳號被判爲異常，重定向到安全頁面，那你是否是須要對302返回碼處理，刪除老的cookie，採用新的cookie，再次發起請求。

再看第二個問題，驗證碼識別：
這個是在登陸模塊裏面，沒錯。可是這個模塊又頗有研究價值，因此我單獨拿出來講。驗證碼的識別本質就是圖片識別。BAT(百度，阿里，騰訊)都作的有對應的圖片識別api，你能夠調用，可是次數多的話，須要錢。可是這些都不是最重要的，重要的是不許，下面來看看究竟有多不許。
百度的OCR api：

騰訊的：只有身份證和名片的OCR，識別效果很差，我就不貼了

阿里的OCR：右邊的SOR4N,2C,X,0是識別結果

我想說，要是效果作成這樣，我也能作。

可是有一家小衆的公司，確實作得好，就是聚合數據，他們的api也是收費的，可是作得挺好，可是他家的在線測試提交不成功，只能用代碼調用，或者用Postman去測試。我測試了10次，9次是正確的，可是須要花錢，註冊免費送50次調用。

固然你是搞圖像的，很簡單，去看論文，把論文裏面的方法實現，估計應該不錯。我不是這行的，我就不去作了，我是用人工輸入驗證碼的。

第三個問題：分佈式爬取數據
這裏面最主要的就是URL去重，防止爬蟲爬重複的東西，scrapy是採用redis來去重的，就是統一管理URL，給每個URL產生一個指紋，當有新的URL時，判斷指紋有沒有出現過，出現過就不放如URL，而後沒出現的都放入待爬隊列裏面。
這個解決方案有問題，由於內存是有限的，生產環境是不能用的（想一想谷歌10000億的URL，就算能存起來，查重也是一個很耗時的問題），而後就得像更好的方法，有的採用布隆過濾器來解決，可是這個方法也仍是沒法徹底解決這個問題。因此就去查看論文，在文章Design and Implementation of a High-Performance Distributed Web Crawler裏面採用內存和磁盤的方式去解決，主要思想是內存裏面維護一顆紅黑樹，而後把紅黑樹不斷和磁盤合併，達到去重的效果。
可是我感受也不是最好的方法，雖然我不知道最好的方法是什麼...

第四個問題：數據存儲
這個裏面主要是分佈式爬去的時候如何把微博數據存起來，通常都是用mongodb，可是單臺mongodb存儲能力有限，因此就須要作mongodb的集羣，這裏就是純工程的問題，你們能夠上網查。不過mongodb集羣存儲仍是蠻有意思的，工程技術能力要求高。

第五個問題：網頁更新
這個應該一直都是學術界研究的問題，google爬下那麼多網頁，如何決定那些網頁須要刷新，畢竟有的網頁是常常改動的，有的又是歷來都不變的。一樣上一篇文章Design and Implementation of a High-Performance Distributed Web Crawle裏面也說了一些方法，但也不是很完美的解決方案，仍是須要你們去探索。

第六個問題：基於關鍵字的微博爬取
咱們爬網頁的時候，不少時候咱們是有意圖的，好比我就只想爬「關於網絡爬蟲」的網頁，其餘的網頁咱們都不要，那怎麼辦？這個也是學術界在研究的問題，如何設計爬取特定主題網頁的爬蟲，畢竟網頁實在太多了，咱們只想去爬對咱們有意義的網頁。固然這裏面就會涉及不少概念背景圖，語義分析的知識，這個時候離散數學就會大展身手了。

總之，上面的每個問題，隨便挑一個，樓主都有不少事去作，並且技術含量不低.....

【參考文章】
Design and implementation of a high-performance ..._百度學術

--------------2015.11.08----------------------
評論區有人很不贊同個人這個答案，而後就開始argue 我，這個可能怪我寫的不夠仔細，仍是讓他們以爲寫爬蟲是一種很low的東西，甚至

@ 螢火

說「調用來調用去沒用到什麼本身的算法，更談不上數學什麼的了」，下面我就針對

@ 足兆叉蟲

，

@ 螢火

兩我的的評論在對這個答案加以補充。
我一條一條來回答。
第一個，模擬登陸，除非是針對某個特定網站，其他通用的解決方法其實就是大量代理 IP 輪着用，很是「沒有技術含量」。我就想問一下，在沒有大量的IP地址可用的狀況下，你有去研究過反向代理IP地址複用的解決方案嗎？

 

第二個，驗證碼，你所謂的「有一家小衆的公司，確實作得好」，後面對接的就是人工打碼，它就是「最沒有技術含量」的方式實現的。是的，我剛開始是人工輸入，可是我後面去研究了驗證碼的識別方案了。現今的驗證碼破解步驟主要有一下幾部：預處理階段、特徵提取階段、驗證碼識別階段和結果修正。預處理階段包含的技術又有：圖像灰度化，背景去噪，二值化，去幹擾線等。特徵的提取有平均切分、橫豎投影切分。最重要的識別階段，方法有模板匹配法，神經網絡法，統計決策法，模糊判斷，SVM，隱馬爾可夫等等，這裏面數學要求仍是極高的

@ 螢火

。

 

第三個，URL去重，生產環境的解決方法就是全存內存，查重都是 O(1) 的，不是一個「很耗時的問題」。內存多便宜啊，全存內存有什麼關係啊。我想了一下O(1)複雜度的查找算法，仍是沒有一個可以解決當前問題的，還勞煩

@ 足兆叉蟲

指教。

 

第四個，你放在 google 的語境下是個問題，可是對於其餘人不必定。對於大部分環境來講，MySQL 就夠用了，就算是 mongodb，那也是工業上已有的實現，搭起來也就是一個「世界上最無聊最沒有技術含量最累的」非「編程活動」。非「編程活動」這個標籤我贊同，可是「世界上最無聊最沒有技術含量最累的」，我就只能呵呵了，一個數據庫集羣不是搭建起來就行了，還有數據故障恢復，性能優化，這些尼？這些都沒有技術含量...

第五個，一樣，你放在 google 語境下是個問題，可是對於大部分人來講，哪些頁面是常常更新的，是「最無聊最沒有技術含量最累的」 heuristic 規則搞得定的。大哥，你簡直就是NB啊，學術界至今沒有很好解決的問題，你用heuristic 規則搞得定，還請指教？難道高手真的在人間，仍是那幫教授太蠢了？

第六個，這個反過來了，「只想爬「關於網絡爬蟲」的網頁」對於 google 來講反而不是一個問題。若是一個特定關鍵詞有足夠多的需求，那麼它必定會有足夠的鏈入連接，它是不會漏掉的。反過來，對於其餘人，這又是一個「最無聊最沒有技術含量最累的」 heuristic 規則搞得定的問題。對於google不是問題，google如今的搜索都是基於爬到的網頁，正反向的索引加上pagerank來作的，請參考《The Anatomy of a Large-Scale Hypertextual Web Search Engine》。若是有一天給定特定主題，爬蟲就能爬到相關的網頁，那麼google還有必要去爬網頁，存儲，建索引嗎？解決這個問題，就意味着Google不在須要開不少機器去爬網頁，不用買不少硬盤存儲，這個能節約多大的費用？至少光電費都節省很多吧。

其實，你上面說的都沒有什麼問題，按照你說的，問題都能解決，可是這些解決方法都不夠好，咱們須要去想更好的方法，不然你們都停留在這個位置，就永遠不會進步了。並且樓主須要的是寫牛逼代碼，而不是爲了爬網頁而爬網頁，咱們回答是給他一個學習的方向，而不是告訴他很low，這些都不用學，沒有意義。

不少在這個答案下說爬蟲很low的人都是爲了爬網頁而爬網頁的人，大家壓根就沒有去思考這個後面所蘊藏的問題。