一个新浪微博的爬虫 a spider of sina weibo
1.正着手以比较优雅的方式实现动态的通过从代理IP提供商的API中实现定时更新本地代理的方式；目前遇到了一些困难，该代理中间件可以被重写，提过的代理IP处理方法仅供参考。
2.优化了seed_uid_spder爬虫的错误处理方法，将爬取的错误处理由spider内部整合到了中间件之中。
3.着手优化weibo_info_spider爬虫的Longtex字段的爬取处理。若某条微博的文本较长，无法从通用的微博内容API获取完整的微博博文内容，需要通过另外的API获取完整的长微博文本内容；但由于pipelines中使用了twisted框架实现的异步插入MySQL数据库的的方法，且由于数据库中长微博博文内容与微博其他内容信息存放在一张表中；即假设现有一条长文本微博待爬取，该条长文本微博中的所有内容信息都以及被爬取处理，且交由pipelines插入数据库之中，但由于抓取该条微博的长文本内容需要生成额外的request请求，且pipelines异步将微博信息插入数据库的顺序不可控，可能导致该条微博的id等关键信息还未插入的数据库时，就需要更新以该id为主键的微博的长文本Longtext字段，可能会导致数据库插入错误。现提出两种解决办法:
1.修改数据库表的结构，将长文本``Longttext``字段单独作为一个表，并以微博的``id``同时为主键与外键，但这样的建表方式同样会存在外键引用不存在造成数据库表冲突的可能
2.以scrapy框架中提供的**信号**即**signal**作为判断依据，实现必须当其余微博关键信息如主键``id``已经插入数据库中时，才执行长微博文本内容``Longtex``的插入
1.完成了weibo_info_spider整个爬虫的调试，已经能够爬取完整的微博信息；修复了之前无法爬取到微博中的视频url链接，图片无法正常插入数据库的bug
2.重新优化了sql_insert/sql_update等语句模板，避免了出现插入具有重复主键数据时引起的错误
3.优化了items，将原来杂糅在一个WeiboInfoItem中的数据信息拆分为多个不同类型的item，避免了在item中添加大量的判断字段来指引pipeline对数据进行清洗，增强了程序的可读性与逻辑性。（过多的判断字段把我自己都整晕了）。
4.重新优化了整个pipelines；现在每个管道通过判断item的类型来决定是否对该item进行处理，而非是通过之前的传递该item的爬虫的name属性，使得整个程序更加科学、健壮
5.为weibo_info_spider提供了单个用户微博爬取的接口，只需指定参数model=s与uid=xxx即可对单个用户的微博进行采集；具体使用方法同可参考user_info_spider
6.计划为weibo_info_spdier提供爬取特定单条微博的接口，但需要指定该条微博的id
7.正着手实现动态代理IP的构建，预计能够快速推出。
8.构建完动态代理IP后，将会把爬虫部署到服务器上进行速度测试；目测速度很快，在有足够的代理IP的条件下，本地Windows主机校园网测试速度可达约4000条?/min
9.优化了日志输入的格式
10.十一快乐
11.发现日志有点丑，可以将就用。。。原来的代理被我误删了。。问题不大，明天推送重新实现的动态代理IP。
1.BUG好多，人生好难，更不动了。
2.第一句纯属废话，整着手实现动态代理IP以及weibo_info_spdier的最后完善，目测能够在10.1之前完成一个完整的微博爬虫。
1.修复了无法插入用户总微博数total_count字段的错误，原因在于重复传递同一个item导致用于判断是否需要更新total_item的字段被覆盖。
2.重新修复了插入图片URL的插入错误，在于pic_info表中的id外键关联了weibo_info的主键id，由于整个使用twisted框架在pipline实现了一个异步插入的process_item方法，所以可能导致在插入pic_url的同时与之关联的微博id还未插入
1.完成了整个wei_info_spider的工作，包括spider、middlewares、pipeline等等，现已可以插入数据库中，基本无bug，但是待进一步调试。
2.修改了middleware中的部分bug，现已经不影响整个爬虫工作。
3.目前还有fans_list_spider 与 comment_info_spider两个爬虫待完善，但整个爬虫已经能够基本正常运作，能够爬取一定量的数据。在不适用代理的情况下，大概一天2w左右的数据？
1.完成了weibo_info这部分爬虫的编写，这部分爬虫是工作量最大的
2.认真阅读了Scrapy相关文档，准备改写已有的seed_uid_spider与user_info_spider这两个爬虫，进行进一步的优化。
3.计划增加WeiboMiddleware这一中间件，用于处理爬取遇到HTTP code：418或者爬取到空数据的情况，将原来处理这一部分的代码从各个spider分散中集合到一个中间件上实现这个这个功能。
4.学习了使用如何使用中间件，领悟到中间件是Scrapy框架的精髓所在(唔)
1.对已有代码进行继续优化，更新之前代码冗余功能重复的部分。
2.对已有的管道进行功能扩充，使得所用爬虫可以通过一个管道来清洗数据。并将原来部分管道由同步代码改写到异步代码
1.重写了seed_uid_spider与user_info_spider。
2.优化了seed_uid_spider，节省了爬虫运行时不必要的内存开销，使用yield关键字对Request对象进行迭代，进行迭代爬取，避免了设置过量的start_urls增加不必要的内存开销。
3.对于user_info_spider，给出了爬取单个用户的信息的API,只需要在运行user_info_spider时指定参数model=single/s并给定爬取用户对应的uid即指定参数uid=xxxxxx就可以爬取单个用户的账户信息。同时并延续之前的工作模式，在使用seed_uid_spider通过爬取超级用户的粉丝列表储存其uid后，对每个uid的相关信息进行爬取，需要指定参数model=auto/a
4.整个Spider将会具有以下几个爬虫，其中所有的爬虫运行都依赖于seed_uid_spider通过爬取超级用户的粉丝列表 ，需要首先运行seed_uid_spider获取大量用户的uid，存入数据库之中，然后其余各爬虫分别根据微博不同的数据接口来获取相关数据。
seed_uid_spider
user_info_spider
weibo_info_spider(待完善)
comment_info_spider(未实现)
follow_list_and_follower_spider(未实现)
5.试图把README写得好看一点，但是好像失败了。
1.重新调整了README.md文件的格式，显得更加美观。
2.现目前完成了user_info_spider的优化与相应功能的完善。这个爬虫位于spider文件夹下的user_info_spider.py文件之中，其实相应的在该文件夹下还有一个spider名为seed_uid_spider，这个爬虫的功能为通过给定的种子用户uid，即粉丝数量庞大的大V用户，爬取他们的粉丝列表，以此来获得大量用户的uid，进一步通过相应的微博用户信息接口来获取微博用户的详细信息。讲道理最近爬虫的推进陷入了停滞，一个很愚蠢的点在于爬取粉丝列表的同时就可以获取完整的用户信息，根本没有必要将uid写入数据库之后再提前再根据对应的api进行数据采集。但是这样的问题在于会限制以后爬虫的功能扩展，我想的是在完善整个爬虫的构建即可以爬取一个微博用户相应的用户信息、微博内容、微博评论内容之后，提供不同的爬虫工作模式，既可以在给定单个用户uid之后爬取相应的信息，又可以根据用户指定的种子用户爬取其粉丝列表的相关信息。最后user_info_spider与seed_uid_spider这两个爬虫应该会被合并为一个爬虫，根据指定的参数采取不同的爬取模式。
3.爬取用户微博时，如果用户微博文本过长，需要跳转到另外的一个url才能获取完整的微博内容，这样会导致产生新的额外开销，但目前没有找到解决这样开销的办法。但与此同时，如何判断该用户微博的文本需要跳转"阅读全文"?利用正则匹配精确度不够高，开销也未知难以接受，这个问题还待解决。
4.开学了，更新速度变慢了，课程作业有点多，但是每周还是会推进项目更新，大创结题压力有点大，说不定后面还得熬熬夜赶一赶。
1.重新排版了READM.md文件，虽然还是有点丑，但是会后期继续完善
2.正着手思考解决如何限制爬虫被死锁在一个返回结果为空或者无法爬取到的url的情况
2.新增了对同一url重复爬取次数限制，新增在settings.py文件中的'WEIBO_INFO_SPIDER_REPEAT_TIME'字段中，默认设置为5次。同时新增字段'USER_INFO_SPIDER_SLEEP_TIME'
即用户可以自行设置收到418状态码时程序的休眠时间，默认为60s
3.正着手编写具体每一条微博的爬虫爬取，但是发现一个问题。目前针对某一个用户的微博爬取，采取了用户自行设置爬取页数的范围。但如果某一用户的微博数量页数小于爬取页数的区间，将会导致整个爬虫锁死在返回数据为空的url连接上。导致这个情况的原因是，在某些情况下爬取微博的url会返回一个空的json数据，需要重新爬取处理，但此时返回的数据与请求微博用户不存在页数时返回的数据完全一样，导致无法区分究竟是爬取失败还是该页面本来就不存在，正思考如何解决。
2.新增了某一URL爬取失败的处理，会根据爬取失败的具体情况重新生成Request对象进行爬取数据。（注：但在更新写readme的时候突然想到没有避免爬虫被锁死在这个url上的情况，即若这个url一直爬不下来，爬虫将会一直爬，这个坑后面填）
这是一个基于Python Scrapy框架的新浪微博爬虫
Python3.7 MySQL5.7 Scrapy 1.5
1.这是一个通用的微博爬虫，目前暂时只实现了微博用户信息采集的功能，具体每一条微博的信息采集正在实现中
2.速度不够快，跑一个晚上大概也就10000条数据左右，没有实现代理ip，因为穷，所以买不起一天20+的代理ip，而且懒，所以不想自己去慢慢找能活得久一点的代理
3.本来做这个爬虫是为了大创的数据采集来用，最近刚开学事情不多所以会更新比较频繁，具体每一条微博的采集功能正在逐渐实现
4.第一次学习使用Scrapy框架，而且也算是第一次正式的用GitHub，前几天写的代码着实太愚蠢，但微博爬虫工作很繁琐，没有时间去修改之前写得太蠢的地方，准备一边继续写一边继续优化
5.现在大概爬了四万条左右的用户信息数据，主要爬取的网站是 m.weibo.cn 微博的移动站
6.相对PC站而言m站更容易获取数据，而且相对而言数据更加工整（ajax请求返回的json数据）更容易被提取出来，不需要进行模拟登陆，所以选择了对m站的数据进行爬取
7.数据库在我本地建好了已经，但是最近事情还是有点多，其实是我懒，所以我暂时先不把数据库表放上来（这坑以后会填）
8.最后说一点数据库，数据的插入用到了Twisted框架，实现了将爬取到的数据异步插入，从而在某种程度上规避了通常意义上的同步插入给爬虫带来的运行阻塞
进入项目的目录
运行 scrapy crawl xxxspider
爬虫会自动运行爬取数据，但现在可能还暂时跑不了，因为项目前半部分对Scrapy框架还不熟悉就开始写了，着实写得有点蠢
虽然嘴上说着穷，不过还是得把代理给搞定，没有那玩意爬取速度还是太慢了，不过问题不大，主要是没钱（留下了贫穷的泪水）在所有功能完善，bug改完之后，准备租一天的代理把代理给实现了，代理有爬取速度就上去了，说多了都是泪
完成单机上的爬虫之后，准备实现把这个爬虫扩展为分布式的爬虫，用Scrapy-Redis框架