Scenario： 有多少网页， 有多长，有多大
Service: Crawler, TaskService, StrorageService
Storage: Use db To store task, 用 big table存网页

网络爬虫是一个写多读少的系统： webcrawler

设计一个新闻爬取系统
send http request, grab contents of the news list page
extract all news titles from news list page

常见问题：
单线程为什么要比多线程要慢？因为这里要等。

用深度优先还是用广度优先，广度优先天然带队列

多线程共享队列的问题
每个线程都删队列的头，就会有问题。

分布式web crawler
Queue
URL queue, 1 trillion, 20 * 2 = 40TB 内存 太大了
不能放在内存里面，只能存在硬盘上面，数据库
没法控制顺序， 频率 和优先级， Queue解决不了

Task Table
需要一个task table(DB)，解决优先级和频率的问题
task table
id , url, state, priority, available time (控制频率)
1, http:// idle, 1, 2019-03-04

架构
WebPage storage <-> crawler <-> task table(dB)

其他问题
表太大的话需要拆表
拆表 但是就有一个scheduler 因为在不同的服务器上

Exponential back off, failure的情况或者不怎么更新的网页

Dead cycle， 某些网站总是只指向它自己。每个巨型网站不能超过多少的限额

爬虫的组件
下载任务

解析任务

检测任务

调度中心

任务队列

数据仓库

代理任务

其实整个系统看起来就是消费者和生产者的关系，所以需要一个装载任务的容器，那么这个容器要有基本的要求：断点续传，能够在项目意外暂停的时候，保存未消费的任务状态，记录已经消费的任务状态，这样当项目重启的时候，能够加载未消费的任务然后继续消费？给出两种方案：
一、通过数据库记录每一条任务的状态，比如添加一个selected字段标识这条任务是否在队列，添加status字段标识这条任务是否被消费过，一旦任务消费了，立马改变status字段状态，selected状态，这样系统突然停止的话，根据selected标识还未被消费的状态，然后把这部分数据添加到系统的任务队列之中，这样的策略虽然能够达到要求，但是不足的地方要不断的和数据库进行通信，要经受大量的写请求，那么要求数据库对表级锁的支持要必须好，性能方面不适合大规模的抓取任务。
二、通过文件存储来实现对任务状态的记录，每次任务队列中拿到的数据都会存储到一个文件中，按照文件大小做rollingFile,那么每一个新的任务加进来，都会首先被放到一个head文件，当head文件不停增长的时候，到一定大小的时候，一个新的head文件就会被加进来，同时有一个checkpoint的文件，记录任务的消费状态，难么当系统异常重启的时候，通过checkpoint文件定位到已经消费到的文件位置，然后把对应位置以后的所有任务都添加到任务队列中，达到记录任务的状态与持久化存储。

Zookeeper负责管理系统中的所有服务，简单的配置信息的同步，同一服务的不同拷贝之间的负载均衡。它还有一个好处是可以实现服务模块的热插拔。

　　URLManager是爬虫系统的核心。负责URL的重要性排序，分发，调度，任务分配。单个的爬虫完成一批URL的爬取任务之后，会找URLManager要一批新的URL。一般来说，一个爬取任务中包含几千到一万个URL，这些URL最好是来自不同的host，这样，不会给一个host在很短一段时间内造成高峰值。

　　ContentAcceptor负责收集来自爬虫爬到的页面或是其它内容。爬虫一般将爬取的一批页面，比如，一百个页面，压缩打包成一个文件，发送给ContentAcceptor。ContentAcceptor收到后，解压，存储到分布式文件系统或是分布式数据库，或是直接交给ContentParser去分析。

　　CaptchaHandler负责处理爬虫传过来的captcha，通过自动的captcha识别器，或是之前识别过的captcha的缓存，或是通过人工打码服务，等等，识别出正确的码，回传给爬虫，爬虫按照定义好的爬取逻辑去爬取。

　　RobotsFileHandler负责处理和分析robots.txt文件，然后缓存下来，给ContentParser和URLManager提供禁止爬取的信息。一个行为端正的爬虫，原则上是应该遵守robots协议。但是，现在大数据公司，为了得到更多的数据，基本上遵守这个协议的不多。robots文件的爬取，也是通过URLManager作为一种爬取类型让分布式爬虫去爬取的。

　　ProxyManager负责管理系统用到的所有Proxy，说白了，负责管理可以用来爬取的IP。爬虫询问ProxyManager，得到一批Proxy IP，然后每次访问的时候，会采用不同的IP。如果遇到IP被屏蔽，即时反馈给ProxyManager，ProxyManager会根据哪个host屏蔽了哪个IP做实时的聪明的调度。

　　Administor负责管理整个分布式爬虫系统。管理者通过这个界面来配置系统，启动和停止某个服务，删除错误的结果，了解系统的运行情况，等等。

　　各种不同类型的爬取任务，比如，像给一个URL爬取一个页面( NormalCrawler)，像需要用户名和密码注册然后才能爬取( SessionCrawler )，像爬取时先要输入验证码( CaptchaCrawler )，像需要模拟用户的行为来爬取( Simulator )，像移动页面和内容爬取( MobileCrawler )，和像App内内容的爬取( AppCrawler)，需要不同类型的爬虫来爬取。当然，也可以开发一个通用的爬虫，然后根据不同的类型实施不同的策略，但这样一个程序内的代码复杂，可扩展性和可维护性不强。

　　一个爬虫内部的爬取逻辑，通过解释从配置文件 CrawlLogic 来的命令来实现，而不是将爬取逻辑硬编码在爬虫程序里面。对于复杂的爬取逻辑，甚至可以通过用代码写的插件来实现。

　　ContentParser根据URLExtractionRules来抽取需要继续爬取的URL，因为focus的爬虫只需要爬取需要的数据，不是网站上的每个URL都需要爬取。ContentParser还会根据FieldExtractionRules来抽取感兴趣的数据，然后将原始数据结构化。由于动态生成的页面很多，很多数据是通过Javascript显示出来的，需要JavascriptEngine来帮助分析页面。这儿需要提及下，有些页面大量使用AJAX来实时获取和展示数据，那么，需要一个能解释Javascript的爬虫类型来处理这些有AJAX的情形。

　　为了监控整个系统的运行情况和性能，需要 Monitor 系统。为了调试系统，保障系统安全有据可循，需要 Logger 系统。有了这些，系统才算比较完备。

　　所有的数据会存在分布式文件系统或是数据库中，这些数据包括URL( URLRepo)，Page( PageRepo )和Field( FieldRepo )，至于选择什么样的存储系统，可以根据自己现有的基础设施和熟悉程度而定。

　　为了扩大爬虫系统的吞吐量，每个服务都可以横向扩展，包括横向复制，或是按URL来分片(sharding)。由于使用了Zookeeper，给某个服务增加一个copy，只用启动这个服务就可以了，剩下的Zookeeper会自动处理。