黄兵的个人博客

最近反爬虫的一些总结

在线接收短信已经上线3个多月了，期间也经历了很多，遇到了很多困难，但是这些都没有什么大的问题，很快被我解决。

今天主要说的是关于网站反爬虫的一些事。为什么要说这些呢？因为有必要，所以要说。

随着网站上线，用户逐渐增多，当时数据库和web服务器在一个机器上面，用户的增加导致CPU经常90%+，不得以在2018年11月5日增加了一台配置很低的web服务器，具体什么配置，在此就不好意思说了，免得大家笑话。

才开始速度很快，但是运行了一段时间之后，CPU也经常在高位。

下面是CPU使用率的一个截图（点击图片可以放大）：

从12月22日CPU突然变得很高，经常100%。爬虫应该在这个时候盯上了我的网站，可以看到22号至29号，完全是满负载。

这几天一直关注网络异常流量，不断封IP，但是对方使用的是爬虫可以一天24小时不间断，我是一个人，没法跟机器比拼，况且我也有自己的事情需要做。

当时这几天一直有告警短消息给我发来，半夜12点听到这些消息，使我难以入睡，但是明天还要工作，就这样开始了研发反爬虫的决心……

一方面我开始重新迁移数据库，购买了一台性能更强劲的MySQL数据库服务器，2018年12月28日购买开始迁移数据。

下面是新的MySQL服务器迁移之后的CPU占用（点击图片可以放大）：

可以看到迁移数据库之后CPU也是高位，而且Web服务器宽带也出现了瓶颈。现在明白了一个道理：

通过升级服务器来支撑爬虫的抓取是错误的，因为你升级服务器的同时，爬虫开启更多的线程，调整速率，服务器各项指标也会爆表。

期间由于爬虫对于服务器的CPU占用，导致正常用户访问也很缓慢，损失了一些用户。

之后又将占用MySQL数据库性能的一些查询放到Redis数据库。

2018年12月23日又增加了一台Redis数据库，这个数据库主要是对于网站求和的操作进行优化。

统计总共多少条短信内容是对数据库的短信内容过滤求和，用户每一次访问都需要重复上面操作，对于性能来说损失很大，所以使用了Redis的INCR来统计数据。

现在降低了一部分MySQL数据库的压力，但是对于爬虫1秒钟访问20多页来说，还是没有解决问题。

现在需要收集用户的一些访问原始数据，开始分析爬虫。

主要是收集ip user_agent 访问时间。这些足够了，当然正常访问用户也不要慌，因为这些信息完全定位不到你是那个人。所以不存在隐私泄露的风险。

当然统计这些数据，肯定还是Redis莫属，为啥？内存型数据库，读写都很快，对于网站一点点速度上的损失，对于用户来说都很明显。

统计了几天的数据之后，开始分析数据。

首先是看看1秒钟一个IP最多能访问多少页，统计数据出来了之后触目惊心，1秒钟20多页，还是连续的。你说这服务器怎么承受的了？

以前的一些爬虫直接封IP，但是这次的爬虫应该使用了代理，大量的不同IP，你根本封不过来。

看样子是老手，之后根据这些统计的数据，设定每个时间段的阈值，操作指定次数，IP进入黑名单，封你没商量。

在处理这些原始数据的时候，Redis的QPS高达3000+个/s的数据处理速度，可以胜任100W级别的网站了，下面是处理原始数据的时候，Redis的一些指标：

每天产生大量的数据：

有一些爬虫会抓取最新内容，流量很少，但是累积起来抓取的页面很多，所以这个时间段设置的很长，但是频次设置的很低，就是防止漏掉这种蛰伏的爬虫。

经过不断完善程序，现在虽然有一些爬虫，但是对网站整个新能没有造成很大的影响。

等着后面不断的记录数据，有了丰富的原始数据，采用深度学习，避免误杀正常用户。

现在还有一些问题需要解决：

1、原始数据的存储；

2、深度学习的问题；

3、事态感知（及时性）。

后面不断优化这个反爬虫程序，努力做成一个产品吧。

也通过这次反爬虫，学到了很多内容。不断进步，使自己更优秀吧！

黄兵个人博客原创。

转载请注明出处：黄兵个人博客 - 最近反爬虫的一些总结