一面结束，总结爬虫的一些小问题，抛砖引玉

上午去面试了腾讯，然后问到了爬虫的问题，结果很多都想不起来了。所以写个帖子总结有关爬虫的种种问题，顺便也方便些其他找实习的同学，第一次笔试没想到会拿到面试，已经很好运了，再攒攒人品。

A 假设，要写一个爬虫，抓取新浪网的数据，那么需要怎样设计？

B 新浪网本身肯定是防爬虫的，那么常见防爬虫的方式有哪些？

C 如果使用 hash 来保证不会出现重复爬取的 url ，如果出现了 hash 碰撞的情况怎么办？

针对问题B，常见网站防止爬虫的基本思路就是爬虫在某些方面比人强，某些方面比人差，因此，如果某些访问请求访问的频率大于某个阈值时，我就可以使用验证码来判断请求发起者是不是人，这一点我用 ss 翻墙的时候经常遇见 google 这么干，当然有的简单验证码是可以通过 python 一个光学识别的包来通过的，北邮教务处登录的验证码就属于这种比较弱的验证码，这种方法最直接的想法是降低请求频率。

还有一部分网站利用爬虫不能解析 js 的功能来动态生成页面，从而防爬虫，这一点主要是抓北邮人论坛，和微拍热门的时候遇到过，破解方法是找到那个 js 访问的网址，然后获得 json 数据就成了，记得 chrome 里是按 F12 浏览 network 即可。
还有一些简单爬虫根本没法解决的问题，比方说页面动态变化，还有就是如果某个“人”访问了除了探测根本看不到的网站，那他就是爬虫，封他没问题，亦或某些很独特的验证码比方说什么“写出来质能方程”，这种真的我不知道怎么针对了。

针对问题A，首先估测新浪网的数据量，假设每天产生 1000 条新闻，那么单是新闻就是 1000365 条的量，打开新浪可以看到光是分站就是 60 个，整个新浪的 url 量就是 1000365 （天）60 （个分站）15 （年）=4.38*10^8 ，这里我忘了我是什么时候用的新浪，姑且从 2000 年开始计算，认为是 16 年，为方便计算认为是 15 年。新浪的数据只会比它多，而不会比它多，而不会比它少。为此直接的想法时使用多线程爬虫，多个爬虫同时爬取，除了使用多线程还可以使用分布式的大型爬虫，只有这个样子才可能爬完这么多（ orz ），然而新浪必然有自己的频率反爬虫机制，因此我们的爬虫还得使用代理（也得限制频率），随着一段时间更换一个代理，降低爬虫被封的危险。现在又有另外一个问题，我今天爬了一次新浪，存了数据，过了几天接着爬，还要再重新爬取一遍么？ http 协议里我记得有个字段是 If-Modified-Since ，同样可以利用这已经缓存过的 url 网址是否改变过，改变了我们再从新爬去，没改变就不用从新爬取了。会有这种问题，不同平台的爬虫可能会爬取同一个链解，造成资源的浪费，怎么办。这点我想的是某个爬虫必须自己保存已经访问过的 url 网址，同时还得有一个总的索引来保存所有已经访问过 url 网址，这点我直接想到的答案有点类似 dns 轮询了， master 爬虫靠 slave 爬虫爬取不同分站的 url ，当遇到其他分站的 url 时，不去访问，遇到同一个分站的时候先问 master 哪个主机可能存储了这个信息， master 给出另一台 slave 地址，然后我直接去问你访问了没？同时为了节省空间，每个爬虫直接存储 url 的 hash 值，而不是 url 网址。当然这个东西直接引出了问题 C

针对问题C,不同爬虫保存 hash 值，可能会遇见 hash 碰撞的情况，怎样应对这种情况呢？直接想法是在增加存储的信息，考虑的是我如果把 url 和 hash 值存到一起，那我不如直接存 url 呢，所以这个问题我没想到特别好的答案，个人比较觉得中意的想法类似给 url 每个字母在不同位置算加权，构成一个 hash 链，但是也觉得不是很好，这个确实没想到好的答案。期待大神的回复

发现面试还是有点喜欢问你在数据量大的思想下解决问题的能力，所以平时写程序时还是要跳开来看问题，不要被局限。