python爬蟲多進程
一. 關於爬蟲
爬蟲，是一種按照一定的規則自動地抓取互聯網信息的程序。本質是利用程序獲取對我們有利的數據。
反爬蟲，從不是將爬蟲完全杜絕；而是想辦法將爬蟲的訪問量限制在一個可接納的范圍，不要讓它過於頻繁。
二. 提高爬蟲效率的方法
協程。採用協程，讓多個爬蟲一起工作，可以大幅度提高效率。
多進程。使用CPU的多個核，使用幾個核就能提高幾倍。
多線程。將任務分成多個，並發（交替）的執行。
分布式爬蟲。讓多個設備去跑同一個項目，效率也能大幅提升。
打包技術。可以將python文件打包成可執行的exe文件，讓其在後台執行即可。
其他。比如，使用網速好的網路等等。
三. 反爬蟲的措施
限制請求頭，即request header。解決方法：我們可以填寫user-agent聲明自己的身份，有時還要去填寫origin和referer聲明請求的來源。
限制登錄，即不登錄就不能訪問。解決方法：我們可以使用cookies和session的知識去模擬登錄。
復雜的交互，比如設置「驗證碼」來阻攔登錄。這就比較難做，解決方法1：我們用Selenium去手動輸入驗證碼；方法2：我們用一些圖像處理的庫自動識別驗證碼（tesserocr/pytesserart/pillow）。
ip限制。如果這個IP地址，爬取網站頻次太高，那麼伺服器就會暫時封掉來自這個IP地址的請求。 解決方法：使用time.sleep()來對爬蟲的速度進行限制，建立IP代理池或者使用IPIDEA避免IP被封禁。
② python爬取大量數據(百萬級)
當用python爬取大量網頁獲取想要的數據時，最重要的問題是爬蟲中斷問題，python這種腳本語言，一中斷
進程就會退出，怎麼在中斷後繼續上次爬取的任務就至關重要了。這里就重點剖析這個中斷問題。
第一個問題: 簡單點的用動態代理池就能解決，在爬取大量數據的時候，為了速度不受影響，建議使用一些緩
存的中間件將有效的代理 ip 緩存起來，並定時更新。這里推薦 github 這個倉庫
https://github.com/jhao104/proxy_pool ， 它會做ip有效性驗證並將 ip 放入 redis ，不過實現過於復雜
了，還用到了 db ，個人覺得最好自己修改一下。困難點的就是它會使用別的請求來進行判斷當前的ip是否
是爬蟲，當我們過於聚焦我們的爬蟲請求而忽略了其他的請求時，可能就會被伺服器判定為爬蟲，進而這個ip
會被列入黑名單，而且你換了ip一樣也會卡死在這里。這種方式呢，簡單點就用 selenium + chrome 一個一個
去爬，不過速度太慢了。還是自己去分析吧，也不會過復雜的。
第二個問題： 網路連接超時是大概率會遇到的問題，有可能是在爬取的時候本地網路波動，也有可能是爬
取的服務端對ip做了限制，在爬取到了一定量級的時候做一些延遲的操作，使得一些通用的 http 庫超時
（ urllib ）。不過如果是服務端動的手腳一般延遲不會太高，我們只需要人為的設置一個高一點的
timeout 即可（30 秒），最好在爬取開始的時候就對我們要用的爬取庫進行一層封裝，通用起來才好改
動。
第三個問題: 在解析大量靜態頁面的時候，有些靜態頁面的解析規則不一樣，所以我們就必須得做好斷點
續爬的准備了（ PS : 如果簡單的忽略錯誤可能會導致大量數據的丟失，這就不明智了）。那麼在調試的過
程中斷點續爬有個解決方案，就是生產者和消費者分離，生產者就是產生待爬 url 的爬蟲，消費者就是爬取
最終數據的爬蟲。最終解析數據就是消費者爬蟲了。他們通過消息中間件連接，生產者往消息中間件發送待
爬取的目標信息，消費者從裡面取就行了，還間接的實現了個分布式爬取功能。由於現在的消費中間件都有
ack 機制，一個消費者爬取鏈接失敗會導致消息消費失敗，進而分配給其他消費者消費。所以消息丟失的
概率極低。不過這里還有個 tips ， 消費者的消費超時時間不能太長，會導致消息釋放不及時。還有要開啟
消息中間價的數據持久化功能，不然消息產生過多而消費不及時會撐爆機器內存。那樣就得不償失了。
第四個問題： 這種情況只能 try except catch 住了，不好解決，如果單獨分析的話會耗費點時間。但在
大部分數據 （99%） 都正常的情況下就這條不正常拋棄就行了。主要有了第三個問題的解決方案再出現這
種偶爾中斷的問就方便多了。
希望能幫到各位。
③ 為什麼在python里推薦使用多進程而不是多線程
監控一個信號就起一個線程與進程處理。這樣的邏輯是不太合適的。所有的資源都是有限的，如果這樣浪費很快會資源管理失控。
常規的做法是起一個線程池，或者是進程池。 使用線程還是進程取決於你處理的信號的類型。如果計算量大，則需要進程池，如果只是設備等待，比如網路數據收發，則線程也勉強夠用。
信號過來後處理方法有兩種，一種是實時處理，這個沒有好辦法，可以用「微線程」的辦法做，盡量減少處理周期。另外一種是允許少量的延遲。那麼通常的做法是用隊列。將信號放到線程或者是進程池的消息隊列里。然後再由後者分配。
還有一種高效的處理方法，根據信號的值做hash，然後自動分發到不同的CPU或者是伺服器。這個就算是大規模並發處理機制。
通常情況下，比如一個WEB伺服器，它需要獲取一個請求，然後處理響應，可以使用線程模型，或者是進程模型。也是使用典型的池的方法。一個Pool的大於，取決於你的計算 機的計算 能力，內存大小，以及你的並發訪問數量。
所要要啟用多少個呢？假設你的一個信號的處理周期是1秒，你同時有100個信號進來，那麼就需要100個線程或者是進程。