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

上一篇文章《社會化海量數據採集框架搭建》提到如何搭建一個社會化採集系統架構，講架構通常都比較虛，這一篇講一下如何實戰用低成本服務器作到日流水千萬級數據的分佈式採集系統。

有這樣一個採集系統的需求，達成指標： 須要採集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天的數據，因此咱們規劃機器的時候能夠掛接多一點硬盤，或者增長機器。結果庫分表如圖：

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

原創文章，轉載請註明： 轉載自LANCEYAN.COM

本文連接地址: 實戰低成本服務器搭建千萬級數據採集系統