Redis、Kafka 与 Celery：分布式调度三件套的性能权衡

原创于 2025-11-19 10:47:55 发布 · 793 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#redis #kafka #Celery #分布式调度 #Playwright #Selenium #爬虫代理

爬虫代理同时被 3 个专栏收录

382 篇文章

订阅专栏

多线程

58 篇文章

订阅专栏

seleuium

53 篇文章

订阅专栏

——一个基于“抓热点新闻”的真实数据故事

做分布式采集这几年，我越来越确信一件事：真正决定一个采集系统能不能跑得稳、跑得久、跑得快的，从来不是抓取逻辑，而是调度层。
是的，写采集的人最后都会发现：爬得快不快，看你请求发得多不多；爬得稳不稳，看你任务发得好不好。

你可能也经历过类似的场景：
Playwright、Selenium 配置得飞快，代理池也搭好了，worker 也开了几十个，但系统真正一跑起来，问题接二连三——任务堆在队列没人取、worker 忙得要死、任务乱跳、重复抓取、队列挤压、卡死、雪崩。

这时候你才会认真看向后台那三位老朋友——
Redis、Kafka、Celery。

它们是分布式调度的“三件套”，但性格完全不同：
Redis 简洁迅速、Kafka 超强吞吐、Celery 模块齐全。
到底该怎么选？不如让它们在真实场景里跑一轮。

于是我做了下面的实验：

统一抓取“今日头条热点新闻( https://www.toutiao.com) Redis、Kafka、Celery 分别调度同样的任务，看它们的区别到底在哪里。

一、数据目标：抓取今日头条热点新闻

为了让三种调度方案都有统一的“赛道”，我们把抓取任务定义得尽量一致：

目标数据：

新闻标题
详情页 URL
发布时间（如能获取）
来源频道（热点 / 娱乐 / 财经等）

为什么选今日头条？
因为它是典型的“更新速度快 + 内容流动频繁”的数据源，特别适合测试调度系统在高频、密集任务场景下的表现。

热点新闻每几分钟就会刷新一批，这对调度层是很大的压力测试。

二、抓取方式：同一逻辑 + 三种调度方式

为了公平，我们让三套系统共用同一抓取逻辑：

Playwright 负责渲染和抓取
爬虫代理负责隐藏 IP
调度层只负责分发 URL，不参与抓取逻辑

这样可以把差异集中到“调度”本身，而不是抓取代码。

下面是统一的核心采集代码。

Playwright 热点新闻抓取（含代理配置）

"""
Playwright 抓取今日头条热点新闻（适配 Redis / Kafka / Celery）
"""

import asyncio
from playwright.async_api import async_playwright

# ==== 亿牛云代理配置（示例www.16yun.cn）====
PROXY_HOST = "proxy.16yun.cn"   # 代理域名
PROXY_PORT = "12345"            # 代理端口
PROXY_USER = "username"         # 用户名
PROXY_PASS = "password"         # 密码


async def fetch_page(url):
    """抓取页面标题（示例简化版）"""
    async with async_playwright() as p:
        browser = await p.chromium.launch(proxy={
            "server": f"http://{PROXY_HOST}:{PROXY_PORT}",
            "username": PROXY_USER,
            "password": PROXY_PASS
        })
        page = await browser.new_page()

        try:
            await page.goto(url, timeout=20000)
            title = await page.locator("title").inner_text()
            return {"url": url, "title": title}
        except Exception as e:
            return {"url": url, "error": str(e)}
        finally:
            await browser.close()

接下来，我们只替换调度方式。

三、三种调度方式：它们到底怎么“分任务”？

下面我用“对比描述”的方式，而不是表格，让三者的风格区别更加自然地呈现出来。

1）Redis：速度最快的轻量分发员

Redis 在调度系统里就像一个“特别干脆的同事”：
不绕弯、不写日记、不记状态、你丢任务它就发，任务一拿走就没了。

它的逻辑非常简单：
往队列塞任务 → worker 从队列取任务 → 执行

代码示例：

# Redis 调度
import redis
import asyncio

redis_cli = redis.Redis(host="localhost", port=6379, db=0)
QUEUE = "task_queue"

async def worker():
    while True:
        _, task = redis_cli.brpop(QUEUE)
        url = task.decode()

        result = await fetch_page(url)
        print("Redis Worker:", result)

Redis 的特点很好记：
快、轻、简单、好用，是采集队列里最常见的方案。

2）Kafka：为大流量而生的吞吐怪兽

Kafka 的定位完全不一样。
如果说 Redis 是“轻量队列”，Kafka 就是“物流系统”。

它能做到：

单机十几万 QPS
压力再大也不崩
有回溯（offset）
有分区（partition）
有消费组（consumer group）

也就是说：
你任务发得再多，Kafka 都吃得下。

代码示例：

from aiokafka import AIOKafkaConsumer
import asyncio

async def kafka_worker():
    consumer = AIOKafkaConsumer(
        "task_topic",
        bootstrap_servers="localhost:9092",
        group_id="crawler_group"
    )
    await consumer.start()
    try:
        async for msg in consumer:
            url = msg.value.decode()
            result = await fetch_page(url)
            print("Kafka Worker:", result)
    finally:
        await consumer.stop()

Kafka 的关键词只有四个字：
大规模场景。

尤其适合实时新闻流、舆情流、财经行情流。

3）Celery：全功能任务调度中心

Celery 就属于“自带态度的老大哥”：
它不只发任务，还会：

管状态
管任务结果
自动重试
链式调度
分布式执行
Web 后台管理任务队列

这对“采集 → 清洗 → 分析 → 存储”这种流水线场景特别适合。

代码示例：

from celery import Celery
import asyncio

app = Celery(
    'tasks',
    broker='redis://localhost:6379/0',  # 调度层
    backend='redis://localhost:6379/1'  # 结果存储
)

@app.task
def crawl_task(url):
    return asyncio.run(fetch_page(url))