依赖于 scrapy_redis 框架 因为需要修改到连接 redis 和处理新的 redis 数据存储的方式 并且又不能单纯的依赖于 scrapy_redis 所以直接拿 scrapy_redis 进行直接改造，主要是在 redis 的调度以及任务信息的存储上面进行一定程度的魔改。 考虑到多任务实现的框架的处理，所以就需要在一定情况下面进行更加细化的 id存储的调配处理 其中一些核心组件使用到了 scrapy 本身就有的组件，所以这部分也需要进行以插件形式的魔改 这样处理会更集成一点，并且在一定程度上依赖会小一些，不需要对 scrapy_redis 进行二次下载 1/ 考虑 spiderid # 这个是考虑对 spiderid 执行状态的监控 2/ 考虑 taskid # 这个是考虑对 taskid 任务主要的统计 后续的处理再看，先考虑实现功能 #20190505 目前的问题主要是在初始化上面，这里的初始化主要指的是 redis 数据结构设计 一方面要兼具 spiderid 和 taskid，另外还要考虑初始化的时机，确实有点麻烦的。 #20190510 继续补充注释的内容，后续可能要考虑怎么处理后续的结构上的问题。 处理多任务时候怎么让工具更加适配 下次的更新应该会再 scrapy_redis_mod.spiders 这里，主要是实现对任务的调度和处理上。 后续还可能需要突然死机后的重启恢复任务解决方式。很重要。 #20190511 尝试解决脚本传递的技术难点,力求无需特殊脚本处理的脚本传递方法. 尽量在不改变原脚本的基础上实现功能，都是为了方便而已 钩子还是稍微不够长，response 没有钩到，导致请求后回到 parse 函数内的 response 都没有我设置的传递参数 所以需要再测试几次在什么地方挂钩才能钩到这一个参数 #20190512 发现在中间件里面进行挂钩非常的合适，解决了之前各种各样的问题 现在的问题主要出在于怎么将脚本的执行处理干净，经量将脚本传递变得更加方便一些。 为了尽量不破坏源代码，所以就要尽可能的让脚本常驻环境当中，所以，目前将选择使用文件存储的方式来生成文件 用传递脚本的 hash 作为文件名字存储，这样也能对重复的脚本进行去重处理 最后尽然以一种不可思的方式实现了主体的功能。 后续可能需要考虑一些爬虫的配置的传递方面的事情。 目前已经实现了多任务的 scrapy 分布式，不过在于scrapy的配置上面可能还不够好 所以后续需要多看看有哪些配置能够通过 custom_settings 进行传递的 这样会比较方便于后面的开发。 另一方面就是在日志显示上面的开发可能还需要多花点时间进行处理。 #20190513 将 taskid 的生成放在上传脚本这端，这样会更加方便上传端这边获取任务id， 无需考虑若是在任务端生成id 还需要处理怎么回传发送端任务id号的麻烦 #20190514 将任务的启动和关闭做成定时轮询，并且将后续的任务尽可能地完善 目前已经将日志，将各种启动以及关闭的情况做好了。后续需要做的事情就是增加各种功能配置之类的了 像是配置固定的过滤池，像是配置固定的输出队列，像是保持将代码 目前发现一个比较诡异的BUG，虽然稍微有点意识到是在什么地方出现的问题，但是时间有点晚了，改天再想想解决办法 虽然应该直接修改检测任务停止时间就可以解决问题，但是我觉得这样不能根本的解决问题 另外再考虑以下非启动任务的部分怎么处理 spider_objs 的收尾工作，今天就这样了。 一个比较诡异的BUG出现了，任务会莫名其妙的少1个。不过先解决另外一个问题。 增加对不同的 dequeue 和 enqueue 的数量判断，因为有时候判断停止会出现问题。会再长时间拿不到任务队列的数据后， 日志信息就一直不变，就会导致判断任务停止。（任务停止的判断为日志的 md5(str(日志)) 是否长时间保持不变） 现在增加一条对 dequeue 和 enqueue 这两项数字的判断。如果相等并且加上快照的 hash 长时间不变就停止任务。 突然发现部分 push 丢弃的 BUG 是源自于一些网络的关系。并不是程序的问题，勉强松了口气。 改善任务端与 redis 服务的网络环境就行。 后续才发现白天出现的问题以一个最蠢的方式结束了。结果居然是因为 SCHEDULER_FLUSH_ON_START 设置为True的关系 因为每次开启任务后以极快的速度提交了任务，所以会有部分先写入管道的任务被 spider 直接清空管道了。 后续还需要处理非监控停止的 spider 的脚本加载对象的堆积问题，这个得考虑稍微有点麻烦的去重处理。 现在发现，删除对象反而比想象中要花时间，且开发还需要各种麻烦的事情，还会带来一定的程序运行风险。 所以现在决定保持所有的 spider 对象驻留。由于使用 hash 作为key的关系，相同的脚本始终只有一个， 所以实际上对程序的压力降低到了最小。直接驻留就好了。还省下了从 redis 上重新拖脚本的时间。 综合考量，传递并加载的 spider 脚本对象直接驻留在所有的 spider 里面。 将任务停止的检测交给任务段完成即可，一个任务端检测一个或多个任务，这样其实也挺方便。 现在基本上已经完成了最初的框架，后续的任务就3个 1/ 做好任务发送端 2/ 考虑数据接收方式 3/ 做好命令行工具 #20190515 整理一下代码，整理一下思路。 后续需要考虑一下怎么处理日志这类比较麻烦的东西，但这里的开发不像是 vredis 那么麻烦。 这里只需要考虑怎么传日志，怎么接收日志即可。传的话可能需要考虑挂钩处理，这里是个难点。 当然也存在不需要开启日志回传的情况，这样的话也会节省空间。 这样的话，可以考虑在 spider 里面使用 lpushx 来传（存在管道才会推入数据，管道不存在则什么都不做）， 本地就只需要简单的 lpush 一个无意义数据即可，不需要的时候只需要删除日志管道即可。 #20190516 发现了一个关于retry的问题，在程序请求错误的时候会自动进行retry。但是retry的时候会重新创建Request对象 并且这个对象没有将_plusmeta 传递下去，所以我这边不得不魔改了一下retry，替换掉原来的retry类插件 目前使用了 item 传递taskid数据为了保证唯一以及不会对 taskid 名字冲突， 所以使用了 b2b89079b2f7befcf4691a98a3f0a2a2 作为 item新增的key名 但是这样的扩展性并不好，命名方面可能还是稍微有点差了， 另外还需要考虑数据的存放 1/ 需要处理数据库类型（考虑使用对 item 外增字段 mysql 里面存放连接数据库的方式，以及存放方法） 2/ 流数据媒体的存放（考虑使用 steam 外增字段，增加存放方式和存放方法） 数据库的存放执行结束后将执行结果放回 mysql 字段或者外增字段？（可以考虑使用开关配置） 流媒体存放暂时还在考虑中，执行存放后将执行后的信息[例如存放地址等]放到 steam 字段里面。 后续这些存放相关的内容都会以 pipelines 插件的形式进行开发，通过item增加关键字决定是否启动 #20190517 一个关于 python 命令行的坑，之后会稍微修改一下测试方法了。真实的学艺不精。 已经改完测试代码，后续该开始考虑怎么将代码处理干净一些。特别是将scrapy本身自带的一些配置的传递。 不过配置传递涉及到一些处理，有些不太方便现在先搞定一下任务端接收数据方式以及数据存储 1/ 一般数据存入redis是下下策，虽然默认是传入管道的， 这里传入管道的函数可以用 lpushx ，这样是否打开管道权力就交给任务发送端了便于开发。 不过可能稍微有点问题，这里还要多想想。 2/ 增加存储 pipeline 的配置参数 3/ 如果想要直接获取数据，这时可以考虑数据传入管道 #20190528 刚开始处理通过在 item中增加 mysql 字段配置连接数据库的方式来进行数据存储。 目前因为对 sql 不太熟悉，暂时还不能处理超长字符串。 目前使用处理超长字符串的方式是直接使用 MEDIUMTEXT 类型数据存储，该类型最大长度为 16M，足够一般的html文本了。 redis暂时还没处理，暂时考虑将 redis 作为一个中转站，让命令行能够通过配置 -o 直接从这个中转的管道拿数据到本地。 像是在使用 scrapy 原本的命令行一样。