專案介紹
本專案旨在利用高階搜尋功能，爬取微博網頁版的詳細資料。而大多數爬蟲以單執行緒為主，但單執行緒存在資源利用率低的不足，針對這以問題，本專案主要使用如下技術：
（1）多執行緒+協程技術+Redis實現增量式爬蟲。實現過程中存在兩個技術難點：一是使用redis資料傳輸時開銷頻繁，伺服器容易崩潰；二是多執行緒會存線上程搶佔資源的問題，這裡借鑑了多視窗售票的思路解決了問題。
（2）實現爬取不同時間段的資料，包含實時資料、自定義時間段資料，並自動識別資料是否展示完全，儘可能保證資料都能爬取到。
相關技術
增量式爬蟲
增量式爬蟲：指在已有爬取結果的基礎上，僅爬取新增的資料，並對已爬取的資料進行去重。
本專案採用兩種去重，分別是URL去重和資料去重，分別採用Redis、PostGreSQL儲存。
URL去重：需爬取的URL儲存至Redis的set中，若當前爬取的URL已存在set中，則不更新set。
資料去重：將已爬取的資料儲存在PostGreSQL資料庫中，每次爬取前先從資料庫讀取所有已爬取資料，再與當前爬取的資料進行對比，僅爬取新增資料。
多執行緒
即在程序中引入多個執行緒實現任務併發執行，能夠提高CPU的利用率，但存在資源鎖的問題。
非同步協程
由於計算機資源是有限的，不可能存在新的任務繼續建立新的執行緒，這樣無限建立大量執行緒會佔用較多資源，因此，將任務排程最佳化從作業系統核心轉移到程式碼片(程式)中，也就是協程。協程的上下文轉換比多執行緒快。而程序、執行緒都是同步的，協程是非同步的。協程具備同步的程式設計方式又有非同步的效能
但對於計算型的操作，利用協程來回切換執行，沒有任何意義，來回切換並儲存狀態 反倒會降低效能。
IO型的操作，利用協程在IO等待時間就去切換執行其他任務，當IO操作結束後再自動回撥，那麼就會大大節省資源並提供效能，從而實現非同步程式設計（不等待任務結束就可以去執行其他程式碼）。
實現思路
站點分析
不同架構的站點分析見https://www.cnblogs.com/Gimm/p/18190005
考慮API採集數量有限，請求次數有限，移動端資料較少，而網頁端具有高階搜尋功能，雖然限制最大頁數為50頁，但可以細化時間粒度採集更多資料。
由於採集轉發型別的博文會存在重複資料，故僅考慮採集原創博文。
根據高階搜尋功能的所有引數，這裡定義自定義引數有：關鍵詞、時間，固定引數：型別=原創，包含=全部
構造一級頁面URL
