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

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

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

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

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

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

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

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天的數據，因此咱們規劃機器的時候能夠掛接多一點硬盤，或者增長機器。結果庫分表如圖：

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

總結

以上是生活随笔為你收集整理的腾讯 监控系统服务器数据采集,实战低成本服务器搭建千万级数据采集系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。