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

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

　　上一篇文章《构建社会化海量数据采集框架》提到了如何构建社会化采集系统架构。该架构通常是相对空旷的。这篇文章就讲讲如何用低成本的服务器实现每天千万级的数据量。分布式采集系统。网页格式

　　有这样一个采集系统的需求，实现目标：需要采集30万条关键词数据，1小时内采集微博，覆盖四大微博（新浪微博、腾讯微博、网易微博、搜狐微博）。为了节省客户成本，硬件为普通服务器：E5200双核2.5G cpu，4G DDR3 1333内存，硬盘500G SATA 7200转硬盘。数据库是mysql。在这样的条件下我们能否实现这个系统目标呢？当然如果有更好的硬件就不是本文的内容了。现在通过采集

和存储来说明如何实现：mysql

　　1.采集

。目标是在一小时内采集

四大微博30万个关键词对应的数据。可以使用的机器配置就是上面配置的普通服务器。采集服务器对硬盘要求不高，属于cpu密集型操作，会消耗一些内存。估计硬件资源不是瓶颈。获取数据的接口有什么问题？数据库

　　1. 遍历各大微博的搜索API。就像新浪微博API请求一个服务器IP一样，正常的权限限制是10000次/小时，最高权限合作授权是40000次/小时。使用应用程序时，还需要有足够的用户。单个用户每个应用每小时访问1000次，最高权限40000次需要40个用户使用你的应用。要达到30w关键词，至少需要申请8次。如果每个关键词需要访问3个页面，总共需要24个有合作权限的应用。在实际操作中，我们不可能为这个项目开发24个合作权限的应用，所以这种方式不是很合适。新浪微博API限制参考链接。数据库

" />

　　2.通过各大微博最新微博采集

数据。微博刚上线的时候，各大微博都有微博广场，可以采集

最新的微博。分词后，如果有 300,000 个 关键词 保留其中一个，其余丢弃。不过除了腾讯微博和搜狐微博有类似微博广场的功能外，新浪微博和网易微博已经没有这个功能了。此外，根据新浪微博此前公布的数据，注册用户超过5亿，每小时发布微博超过1亿条。如果full 采集

是对数据存储的一个大考验，同样需要大量的系统资源，实际采集1亿条post，可能只有1000w条数据是有用的，浪费了9000w条数据的资源。应用程序接口

　　3、通过各大微博网络搜索，所见即所得的方法，结合反监控系统模块模拟人的正常行为，搜索30万条关键词数据，最大限度地利用资源。为了保证在一个小时内采集到，需要采用分布式多线程的方式，并发采集采集。并发的时候，不能从同一个ip或者同一个ip网段出去，保证对方不会*敏*感*词*我们的爬虫。缓存

　　我们最终采用了第三种方法。目前的运营情况是，所有通过30w关键词搜索得到的微博加起来每天总计1000多w条。新浪和腾讯最多，新浪微博略好。使用6台普通PC服务器，即使一台机器花费7000元，总共4万元的硬件设备也能解决购置硬件问题。整体部署图为：server

　　2. 如何存储和处理采集

到的数据？首先，存储和采集

数据是一个写入密集型操作。普通硬盘能不能支持，mysql数据库软件能不能支持，以后突然变大怎么处理？然后是存储空间的评估。每天增加这么多需要占用大量的存储资源，怎么存储又方便扩展。多线程

" />

　　1、如何存放。正常来说，我们上面配置的服务器，mysql使用myisam引擎一个表最大20w，使用innodb引擎最大400w。如果超过这个数量，查询更新速度就会极慢。这里我们采用比较tricky的做法，使用mysql的innodb存储引擎做一层缓存库，这个缓存库有两张缓存表，每张表只存不到300w的数据，一张表有300多w的数据换个表插到超过300w再换回来就好了。切换成功后，截断数据超过300w的表。切记在没有数据插入时截断以防止数据丢失。这里必须使用truncate而不是delete，因为delete需要查询，索引读写，而delete也会写数据库日志消耗磁盘IO，存储空间并没有释放。Truncate 和 drop 是操作数据库删除数据的比较好的方法。由于有两张表作为数据插入表，使用数据库表的自增id是不合适的，需要一个高速的唯一自增id服务器来生成分布式id。另外，数据库可以完全关闭写事务日志来提高性能，因为当时捕获的数据丢失了再开始捕获，这样数据库可以保持一个比较高性能的状态来完成插入操作。抓取缓存表结果如图：Truncate 和 drop 是操作数据库删除数据的比较好的方法。由于有两张表作为数据插入表，使用数据库表的自增id是不合适的，需要一个高速的唯一自增id服务器来生成分布式id。另外，数据库可以完全关闭写事务日志来提高性能，因为当时捕获的数据丢失了再开始捕获，这样数据库可以保持一个比较高性能的状态来完成插入操作。抓取缓存表结果如图：Truncate 和 drop 是操作数据库删除数据的比较好的方法。由于有两张表作为数据插入表，使用数据库表的自增id是不合适的，需要一个高速的唯一自增id服务器来生成分布式id。另外，数据库可以完全关闭写事务日志来提高性能，因为当时捕获的数据丢失了再开始捕获，这样数据库可以保持一个比较高性能的状态来完成插入操作。抓取缓存表结果如图：另外，数据库可以完全关闭写事务日志来提高性能，因为当时捕获的数据丢失了再开始捕获，这样数据库可以保持一个比较高性能的状态来完成插入操作。抓取缓存表结果如图：另外，数据库可以完全关闭写事务日志来提高性能，因为当时捕获的数据丢失了再开始捕获，这样数据库可以保持一个比较高性能的状态来完成插入操作。抓取缓存表结果如图：

　　二、储物空间。插入的数据需要保存，超过300w后不能截断。我们需要一个程序，在达到300万的时候，在truncate之前同步数据，存储到另外一个库中（我们称之为result库，result库也是用的innodb引擎）。但是，我们每天采集

超过 1000 万条数据，并且每天都在增加。一张mysql表一天就炸了。我们的表不是写密集型的，所以结果数据库可以存储更多的数据，上限设置为500w，但是500万还是存储不了1000万条数据。我们需要对mysql的最终结果进行分库和分表。数据先按时间分机器和数据库，再按数据源分表。比如201301在一台机器上存储hash计算的数据，和 201302 散列计算数据在另一台机器上。到机器后，按照天或半天划分表，例如表名为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天的数据，所以我们在规划机器的时候，可以挂载更多的硬盘或增加机器。结果数据库分表如图：

　　根据这个架构，我们使用开源免费软件和低成本的服务器构建了数千万个在生产中运行良好的数据采集系统。建筑学

　　最新版:2021最新升级版版帝国CMS整站源码《资源汇》虚拟资源下载网源码带采集+手机端

　　帝国CMS全站源码2021最新升级版《资源合集》虚拟资源下载网源码带合集+移动端+百度推送+积分下载+会员中心-毒木源码精品发布

　　本源码采用帝国CMS7.5内核二次开发，优化良好，拥有PPT、文档、文章、游戏下载、软件下载、APP下载等模块，非常强大，可直接用于付费下载虚拟资源站点。它是如何工作的。SEO优化极好，整个站点全静态，非常利于收录！

　　本源码由独木源码网于2021年4月14日升级修复，主要升级内容如下：

　　1.去掉错误的部分代码

　　2.新增H5响应式会员中心

　　3.扣分下载

" />

　　4.集成百度主动推送插件

　　5.增加QQ上网登录

　　还有其他功能，请慢慢发现！可直接用于虚拟资源站运营，欢迎您使用赚钱！

　　环境要求：PHP5.6+MYSQL 注意：虚拟空间不能用，必须是服务器

　　整个站点大小为5.75G

　　PC演示地址：

　　手机演示地址：

　　如果演示站打开慢，请看下面的截图，演示站是我们自己搭建的，请勿盗用！

" />

　　在线下载列表