-
Notifications
You must be signed in to change notification settings - Fork 1.2k
分布式微博爬虫的普通模式与极速模式
之所以会有两种模式,是考虑到各种用户对于微博数据抓取的不同需求。 一类用户主要是为了做某些特定关键词或者其它信息的定时抓取或者更新,这类用户有一个特点:要求程序能稳定运行,其中的稳定包括:程序本身的健壮性和cookies、ip的健康。从另一个角度讲,他们对数据量的要求也没有那么大。另外一类用户,需要短时间进行大规模的抓取数据,较账号而言,他们对数据量更加依赖。根据这两种需求,项目维护者制定了不同的cookie存取策略(感谢yun17的贡献)。
针对普通模式,我们取cookie是按照相对公平的模式,即在存储的时候通过队列对cookie进行存储,即插入队尾,然后在取的时候又按照队列进行获取,即插入队首,取出后立马又把它插入队尾,等下一趟轮询。这样的好处是各个账号的负载基本都一致,不会出现某个账号访问量远远大于别的账号的访问量。不过这样也存在一个问题,无论你多少个账号,被封的时候都会齐刷刷的被封,因为它们都会超过微博能容忍的限度。所以这种方式适用于对数据需求量不是特别大的场景。
再谈谈极速模式。出现极速模式的原因是,微博风控系统封账号会有一定的延迟(大概3个小时),我们需要在这三个小时内,将一个账号资源发挥到极致。通过大量试验,我们发现一个账号最多可以同时在5个IP上使用。所以这种模式的运行机制是:每五个节点使用一个账号,节点以hostname
作为唯一标志,所以大家的分布式节点如果公网ip不同,那么请确定它们的hostname
也不同.然后在某个cookie被封后,又换别的cookie.这种方式是以牺牲账号为代价来获取大量数据的。不过账号的成本很小(一块钱4个或者一块钱20个都可以)。这种方式的话,可以指定celery多个进程同时抓取,并且把配置文件中的最大和最小抓取间隔都调更小,以获取更快的抓取速度。
注意,这两种模式的选取需要修改配置文件spider.yaml 中的mode的值,默认是普通模式,极速模式的值为quick
补充一点,极速模式中3个小时左右的延迟对于话题搜索来讲是不成立的,微博搜索应该是限制最为严格的地方,目前只有把访问速度放慢来防止被ban。