腾讯 监控系统服务器数据采集,实战低成本服务器搭建千万级数据采集系统

上一篇文章《社会化海量数据采集框架搭建》提到如何搭建一个社会化采集系统架构，讲架构通常都比较虚，这一篇讲一下如何实战用低成本服务器作到日流水千万级数据的分布式采集系统。html

有这样一个采集系统的需求，达成指标： 须要采集30万关键词的数据 、微博必须在一个小时采集到、覆盖四大微博(新浪微博、腾讯微博、网易微博、搜狐微博)。为了节约客户成本，硬件为普通服务器：E5200 双核 2.5G cpu， 4 G DDR3 1333内存，硬盘 500G SATA 7200转硬盘。数据库为mysql。在这样的条件下咱们可否实现这个系统目标？固然若是有更好的硬件不是这个文章阐述的内容。现经过采集、存储来讲明一下如何实现：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万元硬件设备解决采集硬件问题。总体部署图为：服务器

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天的数据，因此咱们规划机器的时候能够挂接多一点硬盘，或者增长机器。结果库分表如图：

按照这样的架构，咱们使用开源免费软件、低成本服务器搭建的千万级数据采集系统在生产运转良好。架构