今天大家提出的问题给了我们很大的提醒，搞成多线程的确实是太不方便了。所以我们又提出了一种新的设计，避免多线程的复杂性。请王老师审阅我们的这种思路是否可行？谢谢老师

主要思路是不再针对每个站点都生成一套线程/进程，而是在一个进程里面对所有的站点进行轮询处理。因为task的生成和下载是分开的，所以task 生成的过程是很快的，不用担心这种方式会耽误事；储存的时候也不用每个站点一个表了，可以都放在一个表里。

task生成分成两个模块，如图1和图2，图1是listurl Taskgenerator的大致流程图，图2是detailurl Taskgenerator的大致流程图。

在图1中，程序每隔一段时间就会进行一次循环处理（这个时间间隔由最快的站点的更新速度来确定），每次循环处理中，先去读取本次要处理那些站点（每次都去读，方便新增站点和去除站点），对这些要爬取的每一个站点先判断爬取模式，针对不同的模式做不同的处理，镜像模式的时候，生成一些task就行，不能一直处理，处理一会就等到下一轮，增量模式的时候结合站点的更新周期和上一次更新的时间以及现在的时间判断本次循环是否对该站点进行更新。生成的task都发送到rabbit中，然后对操作记录进行持久化。

在图2中，程序也是在一个循环中，首先读取要处理哪些站点的，然后去数据库中看是否有新的listpage到来，如果有就取出，根据页面来判断应该用哪一个配置文件来对其进行抽取，如果抽取成功了就发送task，如果失败了，就进行报警，此时可以很方便进行更改。

请问王老师这种思路可行吗？谢谢

今天大家提出的问题给了我们很大的提醒，搞成多线程的确实是太不方便了。所以我们又提出了一种新的设计，避免多线程的复杂性。请王老师审阅我们的这种思路是否可行？谢谢老师

主要思路是不再针对每个站点都生成一套线程/进程，而是在一个进程里面对所有的站点进行轮询处理。因为task的生成和下载是分开的，所以task 生成的过程是很快的，不用担心这种方式会耽误事；储存的时候也不用每个站点一个表了，可以都放在一个表里。

task生成分成两个模块，如图1和图2，图1是listurl Taskgenerator的大致流程图，图2是detailurl Taskgenerator的大致流程图。

在图1中，程序每隔一段时间就会进行一次循环处理（这个时间间隔由最快的站点的更新速度来确定），每次循环处理中，先去读取本次要处理那些站点（每次都去读，方便新增站点和去除站点），对这些要爬取的每一个站点先判断爬取模式，针对不同的模式做不同的处理，镜像模式的时候，生成一些task就行，不能一直处理，处理一会就等到下一轮，增量模式的时候结合站点的更新周期和上一次更新的时间以及现在的时间判断本次循环是否对该站点进行更新。生成的task都发送到rabbit中，然后对操作记录进行持久化。

在图2中，程序也是在一个循环中，首先读取要处理哪些站点的，然后去数据库中看是否有新的listpage到来，如果有就取出，根据页面来判断应该用哪一个配置文件来对其进行抽取，如果抽取成功了就发送task，如果失败了，就进行报警，此时可以很方便进行更改。

请问王老师这种思路可行吗？谢谢