Redis 在爬虫中的高阶用法：布隆过滤器、限流、任务队列

在大规模爬虫系统的演进过程中，单机方案很快会遭遇性能瓶颈与架构瓶颈。Redis 凭借其极致的内存读写性能、丰富的数据结构与天然的分布式友好特性，成为构建企业级爬虫系统的核心基础设施。本文深入讲解三大高阶用法：布隆过滤器实现亿级 URL 去重、分布式限流策略规避反爬封禁、任务队列支撑多节点协同调度，并结合工程实践给出可落地的实现方案。

一、布隆过滤器：亿级 URL 去重的内存最优解

1.1 为什么爬虫去重需要布隆过滤器

URL 去重是爬虫的基础能力。传统方案使用 Redis Set 存储已抓取 URL，在数据量达到百万级时尚可接受，但当目标站点拥有千万甚至亿级页面时，Set 的内存开销会急剧膨胀 ------ 每存储一个 100 字节的 URL，加上哈希表的空间开销，千万级数据就需要数 GB 内存，成本极高且性能下降明显。

布隆过滤器（Bloom Filter）以极小的误判率为代价，换取了极致的空间效率。一亿条 URL 仅需约 100MB 内存，是 Set 方案的几十分之一，且查询和写入都是 O (k) 的常数时间复杂度，完美适配爬虫去重场景。

1.2 核心原理

布隆过滤器由一个长度为 m 的位数组和 k 个独立哈希函数组成：

• 添加元素：将元素通过 k 个哈希函数映射到位数组的 k 个位置，将这些位置全部置为 1
• 查询元素 ：同样计算 k 个位置，若任意一个位置为 0，则元素一定不存在 ；若全部为 1，则元素可能存在（存在误判）

关键特性：无漏判、有误判。对于爬虫而言，误判意味着少量未抓取的 URL 被当成已抓取而跳过，只要误判率控制在 0.1% 以下，对整体采集覆盖率的影响可以忽略不计。

1.3 Redis 原生布隆过滤器实战

Redis 4.0 之后通过 RedisBloom 模块提供了原生布隆过滤器，无需手动实现哈希映射。

初始化与基础操作：

bash

运行

# 创建布隆过滤器，预期容量1000万，误判率0.01
BF.RESERVE crawler:bloom:url 0.0001 10000000

# 添加URL
BF.ADD crawler:bloom:url "https://example.com/page/1"

# 检查是否存在
BF.EXISTS crawler:bloom:url "https://example.com/page/1"

Python 爬虫集成示例：

python

运行

import redis

r = redis.Redis(host='localhost', port=6379, db=0)
BLOOM_KEY = "crawler:bloom:urls"

# 初始化布隆过滤器（仅首次执行）
def init_bloom(capacity=10_000_000, error_rate=0.0001):
    if not r.exists(BLOOM_KEY):
        r.bf().create(BLOOM_KEY, error_rate, capacity)

# 去重检查并添加
def check_and_add(url) -> bool:
    """返回True表示URL已存在（或误判），返回False表示新URL并已添加"""
    if r.bf().exists(BLOOM_KEY, url):
        return True
    r.bf().add(BLOOM_KEY, url)
    return False

1.4 参数调优与工程注意事项

容量与误判率的权衡：

• 误判率越低，所需内存越大，哈希函数越多
• 推荐爬虫场景设置 error_rate = 0.0001（万分之一），兼顾采集覆盖率与内存成本
• 容量预估要留有余量，超出容量后误判率会快速上升；RedisBloom 支持自动扩容（子过滤器叠加）

进阶优化：分桶布隆过滤器

对于超大规模站点，可按 URL 哈希前缀分多个桶，避免单过滤器过大导致的热点问题；也可按站点域名分别创建过滤器，便于独立管理和清理。

二、分布式限流：优雅控制抓取节奏

2.1 爬虫限流的特殊挑战

单机限流只需在本地维护计数器即可，但分布式爬虫部署在多个节点上，必须通过中心化存储统一控制速率。Redis 天然适合承担这一角色。

爬虫限流与普通 API 限流的核心区别在于：限流维度是目标站点域名，而非客户端。我们需要控制对每个域名的请求频率，避免触发目标站点的反爬封禁，同时兼顾抓取效率。

2.2 四种限流算法对比

表格

算法	实现难度	精度	突发流量	适用场景
固定窗口计数器	极低	低（边界突增）	允许窗口边界突发	粗粒度限流、简单场景
滑动窗口计数器	中等	中	平滑	大多数通用场景
令牌桶	中等	高	允许可控突发	爬虫抓取、弹性限流
漏桶	较高	高	强制平滑，不允许突发	严格速率控制场景

爬虫场景首选令牌桶算法：桶内积攒的令牌允许短时间内的并发请求，符合批量页面抓取的节奏；长期平均速率严格受控，不会突破目标站点阈值。

2.3 令牌桶限流的 Redis 实现

核心思路：用 Hash 结构存储「剩余令牌数」和「上次补充时间」，通过 Lua 脚本保证读取 - 计算 - 扣减的原子性。

Lua 脚本（token_bucket.lua）：

lua

local key = KEYS[1]
local capacity = tonumber(ARGV[1])    -- 桶最大容量
local rate = tonumber(ARGV[2])        -- 每秒生成令牌数
local now = tonumber(ARGV[3])         -- 当前时间戳(秒)

-- 读取当前状态
local state = redis.call('HMGET', key, 'tokens', 'last_time')
local tokens = tonumber(state[1]) or capacity
local last_time = tonumber(state[2]) or now

-- 计算应补充的令牌数
local delta = math.max(0, now - last_time)
local add_tokens = delta * rate
tokens = math.min(capacity, tokens + add_tokens)

-- 尝试获取1个令牌
if tokens >= 1 then
    tokens = tokens - 1
    redis.call('HMSET', key, 'tokens', tokens, 'last_time', now)
    redis.call('EXPIRE', key, 3600)
    return 1  -- 获取成功
else
    redis.call('HMSET', key, 'last_time', now)
    return 0  -- 令牌不足
end

按域名维度调用：

python

运行

import time
import redis

r = redis.Redis(host='localhost', port=6379, db=0)

# 加载Lua脚本
with open('token_bucket.lua', 'r') as f:
    token_bucket_script = r.register_script(f.read())

def acquire_token(domain: str, max_rate: float, burst: int) -> bool:
    """
    针对指定域名获取令牌
    max_rate: 每秒请求数
    burst: 最大突发请求数（桶容量）
    """
    key = f"crawler:limit:{domain}"
    result = token_bucket_script(
        keys=[key],
        args=[burst, max_rate, time.time()]
    )
    return result == 1

2.4 爬虫限流工程实践

多级限流策略：

1. 全局总速率限制：控制整个爬虫集群的总出口带宽
2. 域名级速率限制：针对每个目标站点独立限流，是核心维度
3. IP 级速率限制：使用代理池时，按出口 IP 维度限流

自适应限流： 可结合响应状态码动态调整速率。当检测到大量 403、429 或 503 状态码时，自动降低对应域名的限流速率；连续一段时间正常后逐步恢复，实现智能调速。

三、任务队列：分布式爬虫的调度中枢

3.1 从 List 到 Stream：队列方案的演进

Redis 提供了多种实现任务队列的方式，对应不同的可靠性需求和复杂度。爬虫场景下，主流方案有三种：

方案一：List 基础队列（简单高效）

使用 LPUSH + BRPOP 实现生产者 - 消费者模型，是最经典的实现。

python

运行

# 生产者：URL入队
def enqueue_task(url):
    r.lpush("crawler:queue:tasks", url)

# 消费者：阻塞式取任务
def consume_task():
    # 阻塞等待，超时5秒
    result = r.brpop("crawler:queue:tasks", timeout=5)
    if result:
        return result[1].decode()
    return None

优点 ：实现极简、性能极高；缺点：不支持消息确认，消费者宕机会丢失任务；无优先级、无重试机制。适合对可靠性要求不高的大规模通用抓取。

方案二：ZSet 优先级队列

当不同 URL 有不同抓取优先级时（如新闻列表页优先级高于历史归档页），使用 ZSet 以优先级为 score 排序。

python

运行

# 入队，priority越大优先级越高
def enqueue_with_priority(url, priority=0):
    r.zadd("crawler:queue:priority", {url: priority})

# 取出优先级最高的任务
def dequeue_highest():
    # 原子操作：取出并删除最高分元素
    result = r.zpopmax("crawler:queue:priority", count=1)
    if result:
        return result[0][0].decode()
    return None

方案三：Stream 可靠队列（生产级）

Redis 5.0 引入的 Stream 数据结构是最完善的队列方案，支持消费者组、消息 ACK、待处理条目（PEL）追踪，具备消息队列的核心可靠性保证。

核心操作：

bash

运行

# 创建消费者组
XGROUP CREATE crawler:stream:tasks crawler_group 0 MKSTREAM

# 生产者添加任务
XADD crawler:stream:tasks * url "https://example.com/page/1" depth 2

# 消费者组读取（>表示读取最新未分配消息）
XREADGROUP GROUP crawler_group worker_1 COUNT 1 STREAMS crawler:stream:tasks >

# 确认处理完成
XACK crawler:stream:tasks crawler_group 1526569488297-0

关键特性：

• 至少一次投递：未 ACK 的消息保留在 PEL 中，可重新投递
• 消费者组自动负载均衡：多个 Worker 自动分配不同任务
• 死信队列：重试多次失败的任务移入死信队列，避免阻塞

3.2 延迟队列与失败重试

利用 ZSet 可以实现延迟重试队列。抓取失败的 URL 不立即重新入队，而是设定延迟时间，避免短时间内重复请求触发封禁。

python

运行

import time

def retry_later(url, delay_seconds=60):
    """延迟指定秒数后重试"""
    retry_time = time.time() + delay_seconds
    r.zadd("crawler:queue:retry", {url: retry_time})

def fetch_due_retries():
    """获取所有到期的重试任务"""
    now = time.time()
    tasks = r.zrangebyscore("crawler:queue:retry", 0, now)
    if tasks:
        r.zremrangebyscore("crawler:queue:retry",  0, now)
    return [t.decode() for t in tasks]

配合重试次数计数器，可实现指数退避重试：第一次失败延迟 30 秒，第二次 60 秒，第三次 300 秒，超过最大次数则移入失败库。

3.3 去重与入队的原子性

分布式场景下，去重检查和入队操作之间存在竞态条件，可能导致同一 URL 被多次入队。使用 Lua 脚本将两步操作原子化：

lua

-- KEYS[1]: 布隆过滤器key
-- KEYS[2]: 队列key
-- ARGV[1]: URL
local exists = redis.call('BF.EXISTS', KEYS[1], ARGV[1])
if exists == 1 then
    return 0  -- 已存在，不入队
end
redis.call('BF.ADD', KEYS[1], ARGV[1])
redis.call('LPUSH', KEYS[2], ARGV[1])
return 1

这是分布式爬虫必须处理的细节，否则在高并发下会出现大量重复抓取。

四、三者联动：完整的分布式爬虫架构

将布隆过滤器、限流、任务队列三者结合，形成一套完整的爬虫运行闭环：

1. 任务生产阶段：解析页面提取新 URL → 经布隆过滤器去重 → 通过 Lua 原子入队
2. 任务调度阶段：Worker 从任务队列拉取任务 → 经过令牌桶限流校验 → 放行或等待
3. 任务执行阶段：发起 HTTP 请求 → 成功则解析页面并产生新任务 → 失败则进入延迟重试队列
4. 异常兜底：超过最大重试次数进入死信队列 → 人工排查后可批量重新入队

推荐的 Redis Key 命名规范：

plaintext

crawler:bloom:{site}          # 布隆过滤器
crawler:queue:tasks           # 主任务队列
crawler:queue:priority        # 优先级队列
crawler:queue:retry           # 延迟重试队列
crawler:queue:dead_letter     # 死信队列
crawler:limit:{domain}        # 限流器状态
crawler:stats:{date}          # 运行统计数据

五、最佳实践与性能优化

5.1 内存优化建议

• 布隆过滤器合理预估容量，避免过度配置
• 任务队列设置合理长度，防止无限增长撑爆内存
• 使用 Redis 过期策略清理历史统计数据
• 大规模部署建议开启 RDB + AOF 混合持久化

5.2 并发性能优化

• 优先使用 Lua 脚本减少网络往返
• 批量操作：BF.MADD、批量入队、管道（Pipeline）
• 限流检查本地加一层令牌缓存，减少 Redis 调用频率
• 读写分离：主节点写入，从节点读取统计信息

5.3 监控与运维

• 监控队列长度，异常堆积及时告警
• 监控布隆过滤器命中率，评估误判率是否符合预期
• 定期导出死信队列，分析失败原因
• 关键数据定期备份，支持爬虫任务断点续爬

结语

Redis 在爬虫领域的价值远不止是一个简单的缓存组件。布隆过滤器用极小内存解决了海量 URL 去重难题，令牌桶限流实现了分布式环境下的精准速率控制，Stream 队列提供了生产级的任务调度可靠性。三者协同工作，构成了分布式爬虫系统的核心骨架。

在实际项目中，不必一开始就引入最复杂的方案。可以从 List 队列 + Set 去重起步，随着规模增长逐步升级到布隆过滤器和 Stream 队列，按需演进才是最佳工程实践。