网络爬虫漫谈

[yorkie]

最近几周，我写了大量的Javascript代码来实现了一个与HTTP有很大不同的服务器模型，我不再关心及时响应问题，我写的程序其实是一个爬虫，它们运行在服务器的某个进程组，然后像客户端一样去访问其它服务器的资源，它们在业务上并不占用任何的Unix Socket端口或TCP端口，它们更像是HTTP服务背后的那个默默支持着他的女人，我更想说的是世界上有男人和女人，我也在想，在目前的服务器世界，也可以分为TCP服务器和爬虫类服务类程序。

目前最深入人心的一个概念便是web了，尽管Mobile走在风口浪尖，尽管App Store踊跃出如此多的优秀应用，但这些东西都会江郎才尽，退居二线，web才是互联网的未来，是天之骄子，而为web打下坚实基础的攻坚部队便是能够顶住十几二十亿个请求的强力Web服务器。面对着服务器压力的暴力增长，为了优雅地解决这个Problem，Geek们当然不期望用简单地增加大量服务器来解决这一难题。

首先，为了可以提高请求并发数量，程序员们想到everything is the datum这句经典名句，于是将所有的请求数据纪录下面，并且按照时间或其它标准把请求排列起来，然后使用另一个进程来处理这个队列，那么问题来了，如果有一个处在队列的任务需要耗费大量的时间或计算机资源，那么排在它后面的请求就会吃大亏。

Geek们又一次想到解决方案：尽量简化HTTP请求的逻辑，基本上就是使得请求到来之后，只是从数据库里取一条简单已有的数据回去，而不需要什么全文搜索、文本处理、排序以及IO之类的耗时费力的过程。但业务在增长，逻辑怎么可能如此简单呢，该做的事情永远需要人去做，此时就诞生了爬虫程序，它们预测HTTP客户端用户所期望的数据，然后把数据提前准备好，通过某一种方式推到用户面前。爬虫程序与HTTP服务器相辅相成，前者简化了后者的流程，后者则强烈依赖于前者。

下面来说说压力：
HTTP的压力很重要，因为压力直观表现在用户量，请求数量在超过一个请求阀值之后，会对服务器产品大量压力，造成服务器程序崩溃。相反，爬虫程序不会因为用户数量的突然增长而失去工作能力，无非是遭到HTTP服务器的抱怨，“诶，你怎么还没更新这个用户的数据？”，爬虫左耳朵进，右耳朵出，自己该干嘛还是会干嘛。这一点很讨厌是么，哈哈。

所以一般当这两类服务器遇到服务瓶颈后的做法都不同，HTTP的做法一般是通过修改程序代码（包括前端）来合并请求，缓存数据等，但爬虫最简单管用的做法则是增加硬件提供程序的处理能力。