在爬虫工程里“增量”这两个字意味着你不是把整个互联网拉一遍而是每天定期去目标站点看有没有新东西。真正做过的人都知道增量最难的不是抓取而是判断“这条数据我是不是已经拿过了”。这个判断一旦做错轻则重复抓取浪费带宽重则把对方站点压垮、把自己的IP送进黑名单甚至因为重复写入把数据库撑爆。而Redis之所以能在定时增量爬虫里成为去重的标准答案靠的不是它快而是它把“数据结构”和“过期策略”这两件事做到了恰到好处既能当集合用又能当缓存用还能用一套机制同时搞定去重和资源回收。这篇文章我就把自己在几个真实爬虫项目里用Redis做增量去重的完整思路、配置细节和踩坑记录整理出来给正在做定时抓取、增量更新任务的朋友一个可以直接落地的参考。1. 定时增量爬虫为什么偏偏选中Redis做去重先说结论Redis在增量去重这个场景里几乎是不可替代的原因不光是快更在于它的数据结构天生贴合“判断是否见过某个东西”这个需求。而且定时任务跑起来之后Redis既能当运行时的去重仓库又能当任务队列还能当状态存储一个进程解决三件事。1.1 SADD天然就是“见过没有”的答案在增量爬虫里核心操作就一个拿到一个URL或者一条数据指纹问Redis“这个东西我来过没有”如果没来过就处理如果来过了就跳过。这个操作在Redis里对应的是SADD和SISMEMBER用集合去重语义上完全匹配。SADD在执行的时候如果元素已经存在返回0如果不存在返回1。就凭这个返回值一个命令同时完成了“判断”和“写入”两件事不需要额外的GET然后SET两步操作也不用担心并发下两个进程同时判定“没来过”导致重复抓取。有人可能会说用MySQL查一下不也行吗行但你要考虑定时任务的执行频率。假如一个任务每5分钟跑一轮每轮扫描5000个链接那就意味着每秒要查十几次数据库如果链接多、并发高数据库的连接数和查询延迟会被拉高而Redis的SISMEMBER在10万级成员的情况下响应时间仍然是亚毫秒级这个差距在定时任务里就是“能跑”和“跑得动”的区别。1.2 同一个Redis还能顺手干别的活增量爬虫不是只需要去重还需要调度。定时任务触发后要把一批待抓取的URL分发到多个worker上这个时候Redis的List结构LPUSH/RPOP或者Stream结构就能直接当任务队列用。去重用Set队列用List状态标记用String用一个Redis实例把分布式的几个组件全串联起来。我自己有个项目就是一台2核4G的小服务器上跑着定时触发器、三个worker进程和一个Redis整个系统非常轻运维成本极低换做用MySQL做去重加上用消息队列做调度至少得部署两三个中间件。1.3 定时增量场景对Redis的独特依赖定时增量爬虫有个特点每一轮任务之间有间隔要么是小时级要么是天级。这就意味着每一轮任务开始的时候上一轮产生的临时数据其实已经没用了比如上一轮的任务队列、上一轮的临时状态标记这些如果不清理Redis内存就会被慢慢占满。Redis提供的过期机制和SCAN清理模式恰好就是为这种“周期性产生临时数据”的场景设计的。你要是用MySQL你还要自己去写定时清理的脚本去删除过期记录而Redis的EXPIRE一个命令就把这个事安排明白了。2. 去重机制设计从URL去重到内容指纹去重去重逻辑看起来简单但真正做增量爬虫你会发现“去重”分好几个层次。URL去重只是第一层更关键的是内容层面的去重。如果对方站点的URL参数带时间戳同一个文章每天URL都在变只看URL根本去不了重。所以一个成熟的增量爬虫体系至少在两个层面做去重校验。2.1 URL层去重最基础的过滤手段URL去重是最简单也最直接的一层防线适用于URL结构相对稳定、参数不随意变化的站点。逻辑就是在抓取之前先SADD一下试试如果返回0说明这个URL已经处理过了直接跳过。import redis r redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) def is_url_seen(url: str) - bool: # SADD 返回 1 表示插入成功之前不存在返回 0 表示已存在 return r.sadd(spider:seen:urls, url) 0这里有个细节值得注意我见过很多人写去重是先SISMEMBER判断再SADD写入两步操作在单进程下没问题但一旦开了多进程或多机部署两个worker可能同时判断“不存在”然后同时去抓取同一个URL就会造成重复。用SADD的返回值一步完成判断和写入才是真正并发安全的做法这也是Redis官方推荐的方式。另一个经验是URL在写入之前最好做一次规范化处理比如去掉#锚点、去掉utm_开头的追踪参数、统一大小写。不然同一个页面因为参数顺序不同可能被当成两个URL导致去重失效。我一般会写一个normalize_url函数按站点特性做裁剪效果立竿见影。2.2 内容指纹去重应对URL变脸和页面更新很多网站的URL天生就“不安分”。例如资讯类站点在URL里带上当前时间戳或者随机数你就算把URL存下来下一轮抓取的时候URL又变了URL去重直接失效。还有一种情况是列表页的URL不变但内容变了——比如一个榜单页面每天更新排名URL永远是那个内容已经在变。这两种情况下只靠URL去重要么漏数据要么重复入库必须在内容层面做指纹。内容指纹的思路是对抓取下来的正文内容做哈希把哈希值存进Redis集合作为第二层去重判断。实际操作中不是对整篇全文做哈希因为正文里可能包含动态生成的推荐位、广告位或者无意义的空白这些内容一变化哈希值就会变导致误判为新内容。正确做法是先抽取正文的关键区域比如标题、正文主体文本、发布时间把它们拼接后做MD5或者SHA1。import hashlib import re def content_fingerprint(title: str, publish_time: str, body_text: str) - str: # 拼接关键字段过滤空白格式后再哈希 raw f{title}|{publish_time}|{re.sub(r\\s, , body_text)} return hashlib.md5(raw.encode(utf-8)).hexdigest() # 抓取完成后做二层判断 fp content_fingerprint(item[title], item[publish_time], item[text]) if r.sadd(spider:seen:contents, fp) 0: # 已存在跳过入库 return这里必须说明一个原因为什么指纹要包含发布时间因为在有些场景里你希望重复内容不被再次入库但如果是文章被更新了比如标题和正文变化了但ID没变你仍然希望更新数据库记录。如果把ID加进指纹那么任何一次修改都能被捕获如果不加ID那就意味着“同样的标题同样的正文”被视为重复适合那些转载类内容的去重。这个取舍取决于你项目的需求两种方案我都用过各有适用的场景。2.3 布隆过滤器当集合成员到达千万量级SADD方案在数据量小的时候没有任何问题但如果你做的是全网级别的增量监控要盯着几十万个页面每天扫描那么几个月下来URL集合可能达到几千万甚至上亿级别。一个URL字符串平均按100字节算一亿条URL就是10GB的数据光内存就吃不住了。这时候就该考虑布隆过滤器。Redis 4.0之后可以通过模块引入BF命令也可以用redis-py的bf模块原理就是用多个哈希函数对元素进行映射把元素信息存储在极小的位数组里。布隆过滤器可以做到判断“一定不存在”是百分之百准确的判断“可能存在”存在一定误判率。放在爬虫里去重场景里误判意味着“明明没抓过但被认为抓过了”丢一两条数据。# 需要安装 redis-py 及 redisbloom 模块 r.bf().create(spider:seen:bloom, errorRate0.001, capacity100000000) # 判断并写入 if not r.bf().add(spider:seen:bloom, url): # 返回 False 表示之前不存在现在已加入可以抓取 pass布隆过滤器的关键参数是errorRate和capacity。errorRate建议设成0.001到0.0001之间太低会导致空间占用变大capacity预估一下未来6个月到1年可能产生的URL总量设置过小会随着插入元素增多而导致误判率急剧上升。我一般在设计阶段做成可配置项后续数据量增长时还可以重新创建并迁移。2.4 两级去重组合策略在实际项目里我不会只依赖一个去重层而是把两层组合起来用。流程是这样第一轮先查URL集合如果URL没见过直接抓取如果URL见过再查内容指纹看内容是否变化如果内容也一致就直接放弃如果内容指纹不同说明页面更新了这时候抓取并更新库同时更新URL集合里对应的指纹信息。这个组合的好处是兼顾性能与准确性。URL查询快大部分重复请求可以直接拦在第一层只有少数URL重复但内容变化的页面才需要走第二次指纹判断。这样Redis的查询压力也是最小的整个增量过程的重复计算量大幅下降。我自己在跑了两个月的任务里大约92%的请求被URL层拦截只有8%会走到指纹层。3. 过期策略让Redis的生命周期跟着任务走如果说去重是Redis在增量爬虫里的“矛”那过期策略就是它的“盾”。定时任务产生的大量临时数据如果不加控制地堆积最终会把内存耗尽拖垮整个Redis实例。过期策略设计的核心思路是让Redis里每一个key的生命周期与业务数据的有效周期保持一致。3.1 三种典型Key的差异化过期时间在定时增量爬虫项目里Redis里大致会存放三类数据每类的生命周期完全不同不能一视同仁第一类是永久去重集合比如URL去重集合和内容指纹集合。这些数据只要站点没有改版理论上需要一直保留所以不设置过期时间。第二类是每轮任务的临时状态比如“本轮任务队列”“本轮抓取失败列表”“本轮正在处理的URL锁”这类数据在任务结束后就没用了理想情况应该设置TTL让它们自动消失避免下一轮任务被脏数据干扰。第三类是短期缓存比如请求频率控制的计数器、验证码出现次数等这类数据的生命周期往往是分钟级或小时级需要精确的过期时间。# 临时任务队列30分钟后自动清理 queue_key fspider:queue:{round_id} r.rpush(queue_key, *urls) r.expire(queue_key, 1800) # 频率控制计数器每60秒重置 r.incr(spider:rate:example.com) r.expire(spider:rate:example.com, 60)3.2 定期任务与清理窗口的配合如果只用过期时间有一个问题Redis的过期删除不是实时的而是惰性删除加定期删除结合。惰性删除是指当key被访问时才检查是否过期并删除定期删除是后台每秒执行一定次数的采样删除。这个机制的后果是在大批量key同一时间过期时Redis可能在短时间内占用内存未及时释放造成内存水位暂时偏高。对于定时任务来说我一般会让过期时间错开不要让几百个key都在同一秒过期。另一个经验是在每轮任务结束之后额外执行一次SCAN清理把该轮产生但未设置TTL的临时key主动删除。不要用KEYS命令它在生产环境会阻塞Redis单线程数据量大的时候能把整个服务卡死几秒钟。用SCAN加模式匹配才是安全做法。def clean_up_by_prefix(pattern: str): cursor 0 while True: cursor, keys r.scan(cursorcursor, matchpattern, count500) if keys: r.delete(*keys) if cursor 0: break clean_up_by_prefix(spider:queue:*)3.3 Redis内存淘汰策略的兜底作用即使设了过期时间也可能因为代码bug或者异常情况导致某些key没有正确设置TTLkey不断累积。在这个时候Redis的maxmemory-policy设置就是最后一道防线。在爬虫场景里我一般把淘汰策略设置为allkeys-lru也就是当内存达到上限时优先淘汰最近最少使用的key。这样即使有遗漏的临时key没有被及时清理它们也会因为长时间不被访问而自然被挤出内存。相较之下noeviction策略会让写入直接报错导致爬虫任务中断这个在生产环境绝对不能选volatile-lru只淘汰设置了过期时间的key对永久集合无效保护性不够。# redis.conf maxmemory 512mb maxmemory-policy allkeys-lru maxmemory-samples 10maxmemory-samples是LRU近似算法的采样数量默认是5调高到10可以让淘汰精度更高但会略微增加CPU开销。如果服务器内存充足可以把这个值设得偏大以保证长期运行后的数据质量。3.4 持久化策略要不要AOF怎么平衡增量爬虫的去重数据一旦丢失代价不只是重新抓取那么简单还可能是重复写入数据库、把对方站点再次请求一遍。所以我强烈建议至少开启RDB快照持久化如果任务重要开AOF也行但要控制落盘频率。我的通常是RDB每天保存一次快照AOF开启但appendfsync设为everysec兼顾安全性和性能。这样最坏情况丢失一秒的数据对爬虫场景完全可以接受。在Redis 6.2及以上版本我还习惯开启aof-use-rdb-preamble让AOF文件以RDB格式开头既减小文件体积又加快重启加载速度。save 900 1 save 300 10 save 60 10000 appendonly yes appendfsync everysec aof-use-rdb-preamble yes4. 增量任务的定时与姿态从触发器到执行器去重和过期策略解决了Redis内部的问题但定时增量爬虫的整体架构还需要考虑“什么时候跑”“怎么编排任务”“抓取到什么程度算一轮结束”。这块的代码虽然不难但设计不好会在运行一段时间后暴露出各种边界问题。4.1 用系统定时器还是内部调度器定时任务的第一选择是系统的crontab配合Python脚本可以做到固定间隔执行。但crontab有个问题它只管“到点启动”不管上一次任务是否结束。如果上一轮跑得慢下一轮又开始两个任务同时跑Redis里的数据还好但数据库写入和网络请求会出现并发冲突。我后来更倾向于在爬虫脚本内部用schedule库或APScheduler做单进程内调度配合一个分布式锁来保证同一时刻只有一个任务实例在运行。Redis的SETNX配合过期时间实现锁非常简单。lock_key spider:lock:incremental # 用 SET NX EX 原子操作加锁10分钟自动释放 acquired r.set(lock_key, 1, nxTrue, ex600) if not acquired: print(上一轮任务仍在执行本轮跳过) return这个锁能解决绝大多数重入问题。如果任务真的超时长达10分钟锁会自动释放但此时上一个任务可能还在跑新的任务又进入还是存在并发风险。稳妥的做法是在任务心跳里续期锁或者每轮结束显式删除锁。4.2 增量任务的四个阶段拆解我习惯把每轮定时任务拆成四步分别对应不同的Redis使用模式第一步是发现阶段扫描目标列表页或者数据源提取候选URL列表。这个阶段产生的原始URL先写入一个临时队列不直接进入去重集合因为可能很多URL是无效的。第二步是过滤阶段从临时队列取出URL执行URL规范化然后向Redis去重集合发起判断。这一步会把大量已抓取过的URL拦截掉产生真正需要抓取的目标列表。第三步是抓取与解析阶段worker并发去抓取页面解析出正文后计算内容指纹进行第二层去重判断最后入库。第四步是清理阶段删除本轮产生的临时key保留去重集合更新状态计数。整个过程里Redis的Set、List、String各司其职井水不犯河水。4.3 失败了怎么办失败队列与轮次补偿定时任务的另一个常见问题是失败处理。网络抖动、目标站反爬、超时、解析异常总会有URL抓取失败。如果失败后直接丢弃下轮也不会再抓就产生了数据缺口。正确的做法是专门维护一个失败集合记录失败URL和失败次数。下一轮任务启动时可以优先从失败集合里取出重试。def record_failure(url: str): key fspider:failed:{date.today()} r.hincrby(key, url, 1) # 设置7天过期超过7天的失败记录自动清理 r.expire(key, 7 * 86400)用Hash存储失败URL和失败次数比用Set多了一个计数维度。重试时可以根据失败次数决定优先级失败次数少的优先重试失败超过3次的先缓一缓甚至放弃这样不会浪费资源在明显有问题的页面上。同时这个Hash本身也设置了7天过期避免历史失败数据无限累计。4.4 同一站点并发控制Redis做令牌桶多worker并发抓取同一个站点时如果火力全开很容易触发对方防火墙。我在项目里用Redis的INCR加过期时间做了一个极简的滑动窗口限流效果非常稳定。思路是维护一个计数器每请求一次就在当前秒的key上INCR一次如果超过阈值就让当前worker等待等下一秒新key创建计数重置。这样每个worker单独做限流不够必须用Redis共享这样所有worker加起来的总请求速率才会被限制住。def can_request(site: str, max_requests: int 10) - bool: key fspider:rate:{site} current r.incr(key) if current 1: r.expire(key, 1) return current max_requests这个方案精度到秒已经足够应对绝大多数站点的频率限制。如果遇到更严格的限制策略可以把窗口调成10秒或者60秒但需要相应调整计数阈值注意别把INCR后的EXPIRE拆成两步否则在极端情况下会有key永远不过期的风险。5. 实测案例一个持续运行半年的增量新闻抓取项目这套Redis方案不是我纸上谈兵而是来自一个真实跑了半年多的项目。我拿它做个复盘把具体的参数配置和遇到的实际问题都摊开来说。5.1 项目背景与Redis实际负载当时做的是一个垂直领域的新闻聚合系统需要每天定时抓取约30个新闻站点的列表页和详情页每轮任务大约产生2万到3万个URL其中大约15%是当天新增的其余85%都是历史重复URL。整个系统由一台2核4G的云服务器承载Redis部署在同一台机器上。Redis实例分配了512MB内存实际峰值占用约260MB。其中URL去重集合存储了约620万条URL记录占用了约180MB内容指纹集合大概260万条占用约55MB剩下的是临时队列和状态数据。去重命中率稳定在96%以上真正每轮需要抓取的URL在800到3000条之间多worker总耗时控制在10分钟以内。5.2 去重数据统计一个值得关注的漏判问题项目运行到第三个月的时候我发现某个站点的内容入库量出奇地少。排查后发现这个站点的列表页URL带了动态的随机参数而且正文底部有一段动态生成的相关推荐模块导致内容指纹一直不稳定。第一次抓取时正文哈希包含了这些动态内容下一次内容变了以后就被当成了新文章但诡异的是入库量反而少了原因是URL层和内容层同时误判。最后定位到root causeURL规范化没有去掉该站点的随机参数导致URL集合大量膨胀而指纹计算又没有排除动态模块导致内容指纹频繁变化两层判断互相干扰。修复方案是给该站点单独写了一个URL规则在规范化阶段直接删除随机参数指纹计算也改成只提取正文的正文主干区域过滤掉底部推荐位。5.3 Redis持久化与内存水位调整运行期间遇到过两次服务器重启。第一次没有开AOF只依赖RDB重启后发现丢了将近一天的去重记录导致大约一万多条URL被重新抓取。好在站点没有反爬没有造成封IP但数据库里出现了大量重复数据清理花了半天时间。那次之后我立刻把AOF打开了配置了appendfsync everysec之后也遇到过几次意外重启数据基本没有丢失。内存水位方面最初maxmemory-policy没有设置默认是noeviction。跑到某天发现Redis开始拒绝写入所有爬虫任务瞬间全部报错。那是在一次临时key没有设置过期时间的事故中暴露出来的触发了OOM command not allowed when used memory maxmemory。后来设置了allkeys-lru并调整了项目代码把所有队列key统一加过期时间类似问题再也没有出现过。5.4 定时周期对Redis高峰的影响定时任务采用每10分钟执行一轮的频率但30个站点分布在10分钟内启动会造成Redis访问的集中尖峰。最初设计是到点同时启动所有站点的抓取任务导致每10分钟有一次Redis的CPU瞬间飙到80%以上SCAN和SADD大量并发执行偶尔还会出现慢查询日志。优化方案是把各站点的启动时间错开比如奇数站点在每小时的00分、20分、40分启动偶数站点在10分、30分、50分启动让Redis的负载平摊开。这是纯业务层面的调度优化不花一分钱成本实际效果却非常明显Redis的CPU尖峰从80%降到了40%左右。6. 新版本特性与替代方案思考使用Redis做爬虫去重是个成熟的方案但并不意味着没有改进空间。Redis自身的新版本和一些替代技术在某些场景下值得关注。6.1 Redis 6.2之后更顺手的小改动Redis 6.2之前用SET做锁要自己拼SET key value NX EX 10这样的命令6.2之后命令行和客户端对NX和EX的同时使用支持得更加规范。另外6.2版本引入了GETDEL、SINTERCARD等新命令SINTERCARD在多个集合求交时可以不返回结果集而只返回数量对于估算两个去重集合的重叠率很有用消耗的带宽更小。SINTERCARD spider:seen:urls spider:seen:contents这个命令在调试和统计阶段比较实用例如想快速估算URL集合和内容集合之间存在多少交集它可以在不传输大量数据的情况下给出数量。6.2 Redis Stack和Bloom模块的价值Redis Stack以前叫Redis Modules把布隆过滤器、CMS等数据结构打包了进来。如果你用Docker部署拉取redis/redis-stack-server镜像一行命令就能拥有BF命令不需要手动编译模块。在需要监控海量URL且对误判率容忍度较高的场景里配合布隆过滤器的增量任务内存开销能压缩到原来的十分之一以下。我在另一个数据量更大的项目里做了对比测试同一批约5000万条URL用Set存储需要约4.8GB内存而用布隆过滤器误判率0.001只需要约90MB内存。这个差距在云服务器上直接对应每月几百块的硬件成本差异。6.3 什么情况下该换掉RedisRedis也不是万能的。如果去重数据量达到十亿级以上单机Redis的内存上限会成为瓶颈这时候要么考虑Redis Cluster分片存储去重数据要么使用更专门的位图存储方案。另外一个情况是如果爬虫任务本身不是高并发、数据量每天只有几百条用SQLite或者MySQL就能轻松搞定去重没必要为了用Redis而用Redis维护一个额外中间件也是成本。不过就“定时增量爬虫”这个需求量而言Redis目前仍然是最均衡的选择——简单、高性能、内存可控、运维成本低再加上社区资料丰富遇上问题基本都能搜到解决方案。我自己的判断是除非数据量突破单机内存极限或者公司架构里已经有了其他更适合的统一存储方案否则Redis就是首选没有之一。7. 踩坑实录与推荐配置清单文章最后我把这几年做爬虫项目积累的Redis配置经验浓缩成一份可直接照抄的清单同时把最容易踩的坑集中列出来给正在搭这套系统的朋友当个参考。7.1 我遇到过的六个高频坑第一个坑是KEYS命令遍历全库。数据量少时没感觉数据量过万后Redis会明显卡顿因为它是全量扫描阻塞所有请求。替代方案一定是SCAN命令配合游标分页处理。第二个坑是设置过期时间时用了两步操作先SET再EXPIRE。如果两步之间进程崩溃key就没有过期时间长期累积会把内存耗尽。正确方案是用SET key value EX seconds或者SETEX这样的原子命令。第三个坑是SADD和SISMEMBER配合使用出现并发窗口。多进程部署时必须用SADD的返回值做判断不要先查再写。第四个坑是内容指纹计算包含了无关动态内容。这会导致指纹频繁变化去重形同虚设。要在提取正文时过滤广告位、推荐位等动态模块。第五个坑是maxmemory-policy设置为noeviction后内存满了直接拒绝写入。线上跑定时任务时千万要提前改成allkeys-lru或者volatile-lru。第六个坑是不开持久化。Redis不用来做缓存而用作去重时它就是业务的关键状态存储不开持久化等于把所有去重记录放在内存碎片上。7.2 一份可直接套用的配置清单bind 127.0.0.1 port 6379 # 内存上限根据服务器实际调整 maxmemory 512mb maxmemory-policy allkeys-lru maxmemory-samples 10 # 持久化配置 save 900 1 save 300 10 save 60 10000 appendonly yes appendfsync everysec aof-use-rdb-preamble yes # 慢查询日志 slowlog-log-slower-than 10000 slowlog-max-len 128# Python端初始化 import redis pool redis.ConnectionPool( hostlocalhost, port6379, db0, decode_responsesTrue, max_connections50, socket_timeout5, socket_connect_timeout5, ) r redis.Redis(connection_poolpool)7.3 关键命令速查表用途命令说明URL去重SADD key url返回0表示已存在内容指纹去重SADD fp_key fingerprint同上分布式锁SET lock_key 1 NX EX 600返回OK表示获取锁临时队列RPUSH queue_key url配合LPOP或BRPOP消费计数限流INCR rate_key配合EXPIRE每秒重置批量清理SCAN cursor MATCH pattern COUNT 500禁止用KEYS统计大小SCARD key查看集合成员数量设置过期EXPIRE key seconds针对已有key追加TTL估算内存MEMORY USAGE key查看单个key占用的字节数7.4 最后一句话的建议定时增量爬虫这种任务本质上是个“长期运转的无人值守系统”稳定压倒一切。宁可多写两行代码把边界情况处理好也别等到凌晨三点被报警短信叫醒。把Redis当成业务的一部分而不是一个临时缓存来对待用前面这套思路去设计去重和过期策略运行起来会省心很多。
