1.2 架构

1.2.1 前言

Cetty 是基于模块化设计的，核心的模块为：Scheduler(seed管理器)、ProcessHandler（抽象前置处理器）、ReduceHandler(抽象后置处理器)，HandlerPipeline(处理器链表)Cetty由四大核心组件组成，前面提到两个抽象处理器，可能会让人觉得有点疑惑，实际上这两个东西就是普遍的爬虫框架中的下载器(download)和持久化器(pipeline)的抽象，Cetty提倡使用本框架的朋友可以灵活自由的去实现和定义满足自己需求的各种Handler，当然，本框架已经自带必备的下载器：HttpDownloadHandler(支持同步和异步)，各位可以根据自身需求选择或者自定义。

以下是Cetty的核心架构流程图：

1.2.2 核心模块介绍

1.2.2.1 Scheduler

Scheduler是爬虫种子(Seed)任务管理器，爬虫整个待爬取的任务都是往这个组件里push，以及下载器需要下载任务时都是从这里取得任务，Cetty 默认使用JDK 自带的LinkedBlockingQueue作为队列，用户可以根据自己的需求去实现这个接口。

1.2.2.2 ProcessHandler

ProcessHandler是一个抽象前置处理器，所谓的前置处理器是指在持久化前的一系列操作，例如：请求预处理、代理配置、下载、解析等操作，Cetty 为用户实现了最基本的爬虫流程：HttpDownloadHandler(下载器)、PageProcessHandler(解析器)，他们都是继承自ProcessHandlerAdapter 这个适配器类，因为在Cetty中他们都是前置处理流程，用户完全可以根据自身需求去继承这个适配器类完成具体业务。

1.2.2.3 ReduceHandler

ReduceHandler是一个抽象后置处理器，所谓的后置处理器是指在解析页面结果之后的一系列操作，例如：内容去重、内容分发、内容分析、内容入库等操作，Cetty仅仅实现了最基本的ConsoleReduceHandler，将解析结果输出至控制台，用户可以根据自身的业务需求去继承ReduceHandlerAdapter 这个适配器类，以实现一系列的后置操作。

1.2.2.4 HandlerPipeline

HandlerPipeline本身是一个双向链表，是整个框架各种Handler的容器，各种handler就是有这个东西来管理着，在项目启动前，用户应该将自己实现好的各种handler通过引导类的addHandler加入到这个容器中，不过值得注意的是用户加入的handler顺序会影响具体的业务处理顺序。

1.2.3 核心类介绍

1.2.3.1 HandlerContext

HandlerContext又是一个小容器，它是每一个handler的载体，实际上HandlerPipeline容器里真正装的是一个个的HandlerContext，他们是一一关联的，之所以加入HandlerContext，是为了让各个handler能进行通信，例如：HttpDownloadHandler 下载器下载完任务后需要将结果向后面的handler传递结果，这时候需要通过调用HandlerContext的 fireProcess() 方法将结果向下一个ProcessHandler传递，同理，你可以调用类似的fireXXXX方法传递给对应的handler，这样就能达到传递的效果，而各个handler实际上本身是解耦的。

1.2.3.2 Payload

Payload是一个请求信息的载体，用户可以为当前的爬虫配置UserAgent、Cookie、TimeOut等配置。

1.2.3.3 Page

Page是从downloadHandler下载完成后返回的一个对象，这个对象中包含了下载的结果、以及待抓取的seed列表等。

1.2.3.4 Seed

Seed是一个任务的最小单元，包含了请求url，请求方法，请求体，请求信息，附加信息。

1.2.3.5 Result

Result是前置处理操作完成后生成的结果，用户可以根据这个结果进行一些列的后置操作。