【轉】實戰低成本服務器搭建千萬級數據採集系統

有這樣一個採集系統的需求，達成指標： 須要採集30萬關鍵詞的數據 、微博必須在一個小時採集到、覆蓋四大微博（新浪微博、騰訊微博、網易微博、搜狐微博）。爲了節約客戶成本，硬件爲普通服務器：E5200 雙核 2.5G cpu， 4 G DDR3 1333內存，硬盤 500G SATA 7200轉硬盤。數據庫爲mysql。在這樣的條件下咱們可否實現這個系統目標？固然若是有更好的硬件不是這個文章闡述的內容。現經過採集、存儲來講明一下如何實現：

　　1、採集，目標是在一個小時內把30萬關鍵詞對應的數據從四大微博採集下來，可以使用的機器配置就是上面配置的普通服務器。採集服務器對硬盤沒有太多要求，屬於cpu密集型運算，需耗費一些內存。評估下來硬件資源不是瓶頸，看下獲取數據的接口有什麼問題？

• 一、經過各大微博的搜索api。就好比新浪微博API針對一個服務器IP的請求次數，普通權限限制是一個小時1w次，最高權限合做受權一個小時4w次。使用應用時還須要有足夠的用戶，單用戶每一個應用每小時訪問1000次，最高權限4w次須要40個用戶使用你的應用。達到30w關鍵詞，至少須要8個應用，若是每一個關鍵詞須要訪問3頁，總共須要24個合做權限的應用。實際操做咱們是不可能爲這個項目作到開發24個合做權限的應用，因此這個方式不是很合適。新浪微博API限制參考連接。

• 二、經過各大微博的最新微博收集數據，微博剛推出的時候，各大微博都有微博廣場，能夠把最新的微博都收集下來，而後經過分詞，若是出現了30萬關鍵詞中的一個就留下，其餘就丟棄掉。不過如今除了騰訊微博和搜狐微博有微博廣場相似的功能，新浪微博和網易微博已經沒有這項功能了。另按照新浪微博以前公佈的數據，註冊用戶已經超過5億，每小時超過1億條微博，若是全量採集對數據存儲是個大的考驗，也須要大量的系統資源，實際採集了一億條，也許就1000w條有用，浪費了9000w條數據的資源。

• 三、經過各大微博的網頁搜索，可見便可抓的方式，結合反監控系統模塊模擬人的正常行爲操做，搜索30萬關鍵詞數據，使資源最大化利用。爲了保證在一個小時採集到，須要採用分佈式多線程模式抓取，併發採集。併發的時候不能從同一個ip或者同一個ip網段出去，保證對方不會監測到咱們的爬蟲。

　　咱們最後採用了第三種方式，目前運行情況爲經過30w關鍵詞搜索獲得的全部微博加在一塊兒總量1000多w條天天，新浪和騰訊最多，新浪微博略勝一籌。使用了6臺普通PC服務器，就算一臺機器7000元，總共4萬元硬件設備解決採集硬件問題。總體部署圖爲：

　　2、存儲，採集下來的數據如何處理？首先存儲採集數據是個密集寫的操做，普通硬盤是否可以支持，mysql數據庫軟件可否支持，將來量忽然增長如何應對？再就是評估存儲空間，天天增量這麼多須要耗費大量的存儲資源，如何存放而且易擴展。

• 一、如何存儲。正常來講咱們上面配置的服務器，mysql使用myisam引擎一張表最多20w，使用innodb引擎最多400w，若是超過這個數量，查詢更新速度奇慢。這裏咱們採用一個比較取巧的作法，使用mysql的innodb存儲引擎作了一層緩存庫，這個緩存庫有兩個緩存表，每一個表只存儲少於300w的數據，有一張表多於300w的數據就切換到另外一張表插入直到超過300w再切換回去。切換成功後，把多於300w數據的表truncate掉，記得必定要沒有數據插入的時候再truncate，防止數據丟失。這裏必定要用truncate，不能使用delete，由於delete須要查詢，要用到索引讀寫，而且delete還會寫數據庫log耗費磁盤IO，存儲空間也沒有釋放。truncate和drop是操做數據庫刪除數據比較好的作法。因爲有兩個表做爲數據插入表，使用數據庫表的自增id並不太合適，須要一個高速的惟一自增Id服務器提供生成分佈式ID。另數據庫徹底能夠關閉寫事務日誌 ，提升性能，由於抓取的數據當時丟失再啓動抓取就能夠了， 這樣數據庫能夠保持在一個比較高性能的狀況完成插入操做。抓取緩存表結果如圖：

• 二、存儲空間。插入後的數據須要保存下來，不能在超過300w後被truncate掉了。咱們須要有個程序在達到300萬時被truncate掉以前把數據同步走，存放到另一個庫上（咱們叫作結果庫，結果庫也是使用innodb引擎）。不過咱們天天採集的數據1000多萬，按天遞增，mysql一張表一天就撐爆了，咱們這個表不是寫操做密集型，因此結果庫能夠存儲多點數據，設定上限500w，可是500萬仍是存不下1000萬數據。咱們須要對mysql最終結果分庫分表。將數據先按照時間分機器分庫，再按照數據源分表，好比201301經過hash計算的數據存放在一個機器，201302經過hash計算在另外一個機器。到了機器後再按照天或者半天分表，好比表名爲 weibo_2013020101 、weibo_2013020112。weibo_2013020101表示2月1日上午一個表，weibo_2013020112表示2月1日下午一個表。光這樣分了仍是不夠，1000w/2=500w，經不起壓力擴展。咱們還須要把表再拆分，好比weibo_2013020101 拆成 weibo_2013020101_1（新浪微博）、weibo_2013020101_2（騰訊微博）、weibo_2013020101_3（網易微博）、weibo_2013020101_4（搜狐微博）。這樣一張表平均就存放 500w/4 = 125w 條數據，遠遠小於500w上限，還能夠應對將來突發的增加。再從存儲空間來算，就算一條微博數據爲1k，一天 1000w*1k=10G，硬盤500G最多存放50天的數據，因此咱們規劃機器的時候能夠掛接多一點硬盤，或者增長機器。結果庫分表如圖：

　　按照這樣的架構，咱們使用開源免費軟件、低成本服務器搭建的千萬級數據採集系統在生產運轉良好。