上一篇文章《社會化海量數據採集框架搭建》提到如何搭建一個社會化採集系統架構，講架構一般都比較虛，這一篇講一下如何實戰用低成本服務器做到日流水千萬級數據的分佈式採集系統。
有這樣一個採集系統的需求，達成指標： 需要採集30萬關鍵詞的數據 、微博必須在一個小時採集到、覆蓋四大微博（新浪微博、騰訊微博、網易微博、搜狐微博）。爲了節約客戶成本，硬件爲普通服務器：E5200 雙核 2.5G cpu， 4 G DDR3 1333內存，硬盤 500G SATA 7200轉硬盤。數據庫爲mysql。在這樣的條件下我們能否實現這個系統目標？當然如果有更好的硬件不是這個文章闡述的內容。現通過採集、存儲來說明一下如何實現：
一、採集，目標是在一個小時內把30萬關鍵詞對應的數據從四大微博採集下來，能夠使用的機器配置就是上面配置的普通服務器。採集服務器對硬盤沒有太多要求，屬於cpu密集型運算，需耗費一些內存。評估下來硬件資源不是瓶頸，看下獲取數據的接口有什麼問題？
1、通過各大微博的搜索api。就比如新浪微博API針對一個服務器IP的請求次數，普通權限限制是一個小時1w次，最高權限合作授權一個小時4w次。使用應用時還需要有足夠的用戶，單用戶每個應用每小時訪問1000次，最高權限4w次需要40個用戶使用你的應用。達到30w關鍵詞，至少需要8個應用，如果每個關鍵詞需要訪問3頁，總共需要24個合作權限的應用。實際操作我們是不可能爲這個項目做到開發24個合作權限的應用，所以這個方式不是很合適。新浪微博API限制參考鏈接。
2、通過各大微博的最新微博收集數據，微博剛推出的時候，各大微博都有微博廣場，可以把最新的微博都收集下來，然後通過分詞，如果出現了30萬關鍵詞中的一個就留下，其他就丟棄掉。不過現在除了騰訊微博和搜狐微博有微博廣場類似的功能，新浪微博和網易微博已經沒有這項功能了。另按照新浪微博之前公佈的數據，註冊用戶已經超過5億，每小時超過1億條微博，如果全量採集對數據存儲是個大的考驗，也需要大量的系統資源，實際採集了一億條，也許就1000w條有用，浪費了9000w條數據的資源。
3、通過各大微博的網頁搜索，可見即可抓的方式，結合反監控系統模塊模擬人的正常行爲操作，搜索30萬關鍵詞數據，使資源最大化利用。爲了保證在一個小時採集到，需要採用分佈式多線程模式抓取，併發採集。併發的時候不能從同一個ip或者同一個ip網段出去，保證對方不會監測到我們的爬蟲。
我們最後採用了第三種方式，目前運行狀況爲通過30w關鍵詞搜索得到的所有微博加在一起總量1000多w條每天，新浪和騰訊最多，新浪微博略勝一籌。使用了6臺普通PC服務器，就算一臺機器7000元，總共4萬元硬件設備解決採集硬件問題。整體部署圖爲：
二、存儲，採集下來的數據如何處理？首先存儲採集數據是個密集寫的操作，普通硬盤是否能夠支持，mysql數據庫軟件能否支持，未來量突然增加如何應對？再就是評估存儲空間，每天增量這麼多需要耗費大量的存儲資源，如何存放並且易擴展。
1、如何存儲。正常來說我們上面配置的服務器，mysql使用myisam引擎一張表最多20w，使用innodb引擎最多400w，如果超過這個數量，查詢更新速度奇慢。這裏我們採用一個比較取巧的做法，使用mysql的innodb存儲引擎做了一層緩存庫，這個緩存庫有兩個緩存表，每個表只存儲少於300w的數據，有一張表多於300w的數據就切換到另一張表插入直到超過300w再切換回去。切換成功後，把多於300w數據的表truncate掉，記得一定要沒有數據插入的時候再truncate，防止數據丟失。這裏一定要用truncate，不能使用delete，因爲delete需要查詢，要用到索引讀寫，並且delete還會寫數據庫log耗費磁盤IO，存儲空間也沒有釋放。truncate和drop是操作數據庫刪除數據比較好的做法。由於有兩個表作爲數據插入表，使用數據庫表的自增id並不太合適，需要一個高速的唯一自增Id服務器提供生成分佈式ID。另數據庫完全可以關閉寫事務日誌 ，提高性能，因爲抓取的數據當時丟失再啓動抓取就可以了， 這樣數據庫可以保持在一個比較高性能的情況完成插入操作。抓取緩存表結果如圖：
2、存儲空間。插入後的數據需要保存下來，不能在超過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
本文鏈接地址:實戰低成本服務器搭建千萬級數據採集系統