做分布式爬虫开发5年，从最初支撑日均10万条数据的中小规模爬虫，到现在负责千万级吞吐的企业级分布式爬虫集群，踩过最多的坑，不是反反爬，也不是数据清洗，而是框架选型错误。

很多新手搭建分布式爬虫时，会陷入“盲目追新”或“跟风选型”的误区——看到别人用Celery就跟着用，遇到性能瓶颈又盲目切换到Ray；或者误以为Airflow只能做调度，不能做分布式爬虫，白白浪费大量重构时间。

事实上，Celery、Ray、Apache Airflow 这三种主流方案，没有“最优解”，只有“最适配”。它们的核心定位、架构设计、性能表现差异极大，适配不同的爬虫规模、技术团队和业务需求。

本文不聊空洞的框架理论，全程以实战为核心，结合我过往5个分布式爬虫项目的落地经验，拆解这三种方案的核心原理、爬虫落地方式、性能实测、优缺点及踩坑记录，帮你快速理清选型逻辑，避免走弯路，找到最适合自己业务的分布式爬虫方案。

一、前置认知：分布式爬虫的核心需求（选型的前提）

在对比三种方案之前，我们先明确一个核心：分布式爬虫的本质，是“任务分发+节点协同+容错兜底” ，所有选型都要围绕自身的业务需求展开，脱离需求谈选型都是空谈。

结合实战场景，分布式爬虫的核心需求可分为4类，也是我们对比三种方案的核心维度：

1. 任务调度能力：能否高效分发爬取任务（如URL队列分发）、支持定时/触发式任务，适配不同的爬取频率；
2. 并发性能：单节点/多节点并发爬取能力，能否支撑目标数据量（日均10万条 vs 千万条）；
3. 容错与可扩展性：任务失败后能否自动重试、节点宕机后能否无缝切换，后续能否快速扩容；
4. 运维与学习成本：框架部署复杂度、调试难度，团队现有技术栈能否快速适配（如Python团队优先考虑低学习成本方案）。

这4个需求，直接决定了三种方案的适配场景。接下来，我们逐一拆解每种方案，再做全方位对比。

二、三种方案逐一解析（实战落地视角，非纯理论）

2.1 Celery：中小规模分布式爬虫的首选（最成熟、最易用）

核心定位

Celery 本质是分布式任务队列，并非为爬虫量身定制，但因其轻量、成熟、Python生态适配性好，是中小规模分布式爬虫的主流选型（日均10万-100万条数据场景）。

它的核心架构很简单：Producer（任务生产者，如爬虫脚本）→ Broker（消息中间件，如Redis/RabbitMQ）→ Worker（任务消费者，如爬虫节点）→ Backend（任务结果存储，可选），刚好契合分布式爬虫“分发URL任务、多节点爬取”的核心需求。

分布式爬虫落地方式（实战代码示例）

Celery 做分布式爬虫，核心是将“爬取单个URL”封装为任务，通过Broker分发到多个Worker节点，实现并发爬取。以下是简化版实战代码（真实项目截取，可直接复用）：

# 1. Celery配置（celery_config.py）
from celery import Celery
import os

# 配置Broker（消息中间件，优先选RabbitMQ，高并发下比Redis稳定）
broker_url = "amqp://user:password@localhost:5672/crawler"  # RabbitMQ地址
# 配置Backend（可选，存储任务结果，如爬取是否成功）
result_backend = "redis://localhost:6379/1"

# 初始化Celery实例
app = Celery(
    "distributed_crawler",
    broker=broker_url,
    backend=result_backend,
    include=["crawler_tasks"]  # 导入任务脚本
)

# 配置并发数、重试策略（贴合爬虫场景）
app.conf.update(
    worker_concurrency=10,  # 每个Worker节点的并发数（根据服务器配置调整）
    task_retry=True,        # 任务失败自动重试
    task_retry_policy={
        "max_retries": 3,   # 最大重试次数
        "interval_start": 1, # 首次重试间隔1秒
        "interval_step": 2,  # 每次重试间隔递增2秒
    },
    task_acks_late=True,    # Worker执行任务时崩溃，任务重新分发（避免任务丢失）
)

# 2. 爬虫任务定义（crawler_tasks.py）
import requests
from bs4 import BeautifulSoup
from celery_config import app
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

# 初始化请求会话（避免重复创建连接，提升效率）
def init_session():
    session = requests.Session()
    retry = Retry(total=3, backoff_factor=1)
    session.mount("http://", HTTPAdapter(max_retries=retry))
    session.mount("https://", HTTPAdapter(max_retries=retry))
    session.headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
    }
    return session

session = init_session()

# 定义爬取任务（单个URL爬取）
@app.task(bind=True, ignore_result=False)
def crawl_url(self, url):
    """
    单个URL爬取任务
    :param url: 待爬取URL
    :return: 爬取结果（标题+内容）
    """
    try:
        response = session.get(url, timeout=10)
        response.raise_for_status()  # 抛出HTTP错误
        soup = BeautifulSoup(response.text, "lxml")
        
        # 提取数据（示例：爬取文章标题和内容）
        title = soup.find("h1", class_="title").get_text(strip=True)
        content = "".join([p.get_text(strip=True) for p in soup.find_all("p", class_="content")])
        
        # 模拟任务失败（用于测试重试机制）
        # if "error" in title:
        #     raise Exception("模拟爬取失败")
        
        return {"url": url, "title": title, "content": content, "status": "success"}
    
    except Exception as e:
        self.logger.error(f"URL: {url} 爬取失败，原因：{str(e)}")
        raise self.retry(exc=e)  # 触发重试

# 3. 任务生产者（produce_tasks.py）
from celery_config import app
from crawler_tasks import crawl_url

# 待爬取URL列表（真实场景中可从数据库/文件读取）
url_list = [
    "https://xxx.com/article/1",
    "https://xxx.com/article/2",
    # ... 批量URL（可千万级，存入Broker队列）
]

# 批量提交任务（异步分发到Worker节点）
def produce_tasks():
    tasks = [crawl_url.delay(url) for url in url_list]
    # 可选：等待所有任务完成，获取结果
    for task in tasks:
        try:
            result = task.get(timeout=30)  # 等待任务结果，超时30秒
            print(f"任务完成：{result['url']}")
        except Exception as e:
            print(f"任务失败：{str(e)}")

if __name__ == "__main__":
    produce_tasks()

实战体验与踩坑记录（核心重点）

• 优点：轻量易部署，Python生态无缝衔接，学习成本低；Broker支持Redis/RabbitMQ，灵活适配不同场景；重试机制完善，任务丢失率低（配置task_acks_late后）；中小规模下（10个以内Worker节点）运维简单。
• 踩坑点1：Broker瓶颈——初期用Redis做Broker，当日均任务量超过100万条，出现任务堆积、调度延迟（Redis不适合高并发任务队列场景），换成RabbitMQ后，堆积问题解决。
• 踩坑点2：Worker负载不均——默认调度策略（round-robin）会导致部分Worker节点任务过多、部分空闲，需自定义调度策略（如按节点负载分发）。
• 局限性：不适合大规模集群（超过20个Worker节点），调度效率会明显下降；不支持复杂的任务依赖（如爬取A页面后，才能爬取B页面的URL）；无原生可视化调度界面，调试、监控不便。

2.2 Ray：大规模高吞吐分布式爬虫的最优解（性能最强）

核心定位

Ray 是分布式计算框架，核心优势是“高性能、高可扩展”，专为大规模数据处理、高并发任务设计，近几年逐渐成为千万级吞吐分布式爬虫的首选（日均100万-1000万条数据场景）。

和Celery不同，Ray 没有“Producer-Broker-Worker”的固定架构，而是采用“节点池+任务调度器”的设计，所有节点（Head Node + Worker Node）组成一个集群，任务直接在节点间分发，无需中间Broker，调度延迟比Celery低一个数量级。

Ray 的核心概念是“Task（任务）”和“Actor（状态ful任务）”，其中Task适合无状态爬取（如单个URL爬取），Actor适合有状态爬取（如维持一个请求会话、IP代理池），刚好适配爬虫的不同场景。

分布式爬虫落地方式（实战代码示例）

Ray 做分布式爬虫，核心是启动Ray集群，将爬取任务封装为Ray Task/Actor，通过Ray的调度器分发到集群节点，实现高并发爬取。以下是简化版实战代码（真实项目截取）：

# 1. Ray集群初始化（head_node.py，Head节点执行）
import ray

# 初始化Ray Head节点（指定端口、密码，允许Worker节点连接）
ray.init(
    address="auto",
    dashboard_host="0.0.0.0",  # 开启可视化仪表盘（便于监控集群）
    dashboard_port=8265,
    _redis_password="ray_crawler",  # 集群密码，防止未授权访问
    num_cpus=8,  # Head节点CPU核心数（根据服务器配置调整）
    num_gpus=0   # 爬虫无需GPU，设为0
)

print("Ray Head节点启动成功，集群地址：", ray.get_dashboard_url())

# 2. 爬虫任务定义（crawler_tasks.py，所有节点均可执行）
import ray
import requests
from bs4 import BeautifulSoup
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

# 初始化Ray Worker节点（连接到Head节点，Worker节点执行）
ray.init(
    address="ray://localhost:10001",  # Head节点地址（替换为实际地址）
    _redis_password="ray_crawler"
)

# 定义Actor（有状态，维持请求会话和IP代理池，避免每个任务重复创建）
@ray.remote(max_restarts=3)  # 节点宕机后，自动重启Actor
class CrawlerActor:
    def __init__(self):
        # 初始化请求会话
        self.session = self._init_session()
        # 初始化IP代理池（真实场景中可对接代理API）
        self.proxy_pool = ["http://127.0.0.1:8888", "http://127.0.0.1:8889"]
        self.proxy_index = 0

    def _init_session(self):
        session = requests.Session()
        retry = Retry(total=3, backoff_factor=1)
        session.mount("http://", HTTPAdapter(max_retries=retry))
        session.mount("https://", HTTPAdapter(max_retries=retry))
        session.headers = {
            "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
        }
        return session

    def _get_proxy(self):
        # 轮询获取代理（简单负载均衡）
        proxy = self.proxy_pool[self.proxy_index]
        self.proxy_index = (self.proxy_index + 1) % len(self.proxy_pool)
        return {"http": proxy, "https": proxy}

    def crawl_url(self, url):
        """单个URL爬取任务（有状态，复用会话和代理）"""
        try:
            proxy = self._get_proxy()
            response = self.session.get(url, timeout=10, proxies=proxy)
            response.raise_for_status()
            soup = BeautifulSoup(response.text, "lxml")
            
            title = soup.find("h1", class_="title").get_text(strip=True)
            content = "".join([p.get_text(strip=True) for p in soup.find_all("p", class_="content")])
            
            return {"url": url, "title": title, "content": content, "status": "success"}
        
        except Exception as e:
            print(f"URL: {url} 爬取失败，原因：{str(e)}，将重试")
            # 重试逻辑（手动实现，可结合Ray的任务重试机制）
            for _ in range(2):
                try:
                    proxy = self._get_proxy()
                    response = self.session.get(url, timeout=10, proxies=proxy)
                    response.raise_for_status()
                    soup = BeautifulSoup(response.text, "lxml")
                    title = soup.find("h1", class_="title").get_text(strip=True)
                    content = "".join([p.get_text(strip=True) for p in soup.find_all("p", class_="content")])
                    return {"url": url, "title": title, "content": content, "status": "success"}
                except:
                    continue
            return {"url": url, "status": "failed", "reason": str(e)}

# 3. 批量提交任务（task_producer.py，Head节点执行）
from crawler_tasks import CrawlerActor

# 创建多个Actor实例（对应多个Worker节点，提升并发）
num_actors = 10  #  Actor数量，根据集群节点数调整
actors = [CrawlerActor.remote() for _ in range(num_actors)]

# 待爬取URL列表（真实场景中可从HDFS/MongoDB读取，千万级规模）
url_list = [
    "https://xxx.com/article/1",
    "https://xxx.com/article/2",
    # ... 批量URL
]

# 批量提交任务（Ray自动分发到不同Actor/节点）
def produce_tasks():
    # 任务分发（轮询分配给不同Actor）
    tasks = []
    for i, url in enumerate(url_list):
        actor = actors[i % num_actors]
        tasks.append(actor.crawl_url.remote(url))
    
    # 异步获取任务结果（非阻塞，提升效率）
    results = ray.get(tasks, timeout=60)  # 超时60秒
    
    # 处理结果（如存入数据库）
    success_count = 0
    failed_count = 0
    for result in results:
        if result["status"] == "success":
            success_count += 1
            # 存入数据库（示例）
            # db.crawler_result.insert_one(result)
        else:
            failed_count += 1
    
    print(f"任务执行完成：成功{success_count}条，失败{failed_count}条")

if __name__ == "__main__":
    produce_tasks()

实战体验与踩坑记录（核心重点）

• 优点：性能极强，调度延迟低（毫秒级），支持大规模集群（100个以上Worker节点），日均千万级任务无压力；无中间Broker，减少性能损耗；Actor模型适配有状态爬取（复用会话、代理池），大幅提升爬取效率；自带可视化仪表盘，便于集群监控、任务调试。
• 踩坑点1：学习成本高——Ray的概念（Actor、Task、Object Store）比Celery复杂，团队需要1-2周的学习时间才能熟练使用；
• 踩坑点2：资源配置不当导致崩溃——初期未限制Actor的CPU/内存使用，部分节点因资源耗尽宕机，需在初始化Actor时配置num_cpus num_gpus，合理分配资源；
• 踩坑点3：任务结果存储压力——千万级任务的结果存储在Ray的Object Store中，会占用大量内存，需及时将结果写入HDFS/MongoDB，释放内存；
• 局限性：轻量级场景（中小规模爬虫）下，部署、运维成本高于Celery，显得冗余；生态不如Celery成熟，遇到小众问题时，解决方案较少。

2.3 Apache Airflow：多源异构、复杂依赖分布式爬虫的首选（调度最强）

核心定位

Apache Airflow 本质是分布式任务调度平台，核心优势是“复杂任务依赖调度、可视化管控”，并非为爬虫量身定制，但适合“多源异构、有复杂依赖”的分布式爬虫场景（如：先爬取新闻列表页，提取URL后，再爬取新闻详情页；多个爬虫任务按顺序执行）。

和Celery、Ray不同，Airflow 的核心是“DAG（有向无环图）”，所有任务都按DAG定义的依赖关系执行，支持定时调度、手动触发、任务重试、失败告警，适合需要精细化管控的爬虫场景（如企业级多源舆情爬虫）。

Airflow 做分布式爬虫，通常需要结合Celery（用Celery作为Executor，实现任务分布式执行），形成“Airflow（调度）+ Celery（分布式执行）”的架构，兼顾调度能力和执行性能。

分布式爬虫落地方式（实战代码示例）

Airflow 做分布式爬虫，核心是定义DAG，将爬虫任务封装为Airflow Operator，配置Celery Executor，实现分布式执行。以下是简化版实战代码（真实项目截取）：

# 1. Airflow配置（celery_executor配置，适配分布式执行）
# airflow.cfg 核心配置（简化）
executor = CeleryExecutor  # 用Celery作为Executor，实现分布式执行
broker_url = "amqp://user:password@localhost:5672/airflow"  # RabbitMQ地址（Celery Broker）
result_backend = "db+postgresql://user:password@localhost:5432/airflow"  # 结果存储（PostgreSQL）
default_timezone = "Asia/Shanghai"  # 时区配置（避免调度时间偏差）
dag_default_args = {
    "owner": "crawler",
    "retries": 3,  # 任务失败重试次数
    "retry_delay": timedelta(minutes=1),  # 重试间隔1分钟
    "start_date": datetime(2026, 2, 1),
}

# 2. DAG定义（爬虫任务依赖调度，dags/crawler_dag.py）
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.utils.dates import days_ago
from datetime import timedelta
import requests
from bs4 import BeautifulSoup
import pandas as pd

# 定义DAG（有向无环图），配置定时调度（每天凌晨2点执行）
with DAG(
    dag_id="distributed_crawler_dag",
    default_args=dag_default_args,
    schedule_interval="0 2 * * *",  # 定时调度表达式
    catchup=False,  # 不执行历史任务
    tags=["分布式爬虫", "多源依赖"],
) as dag:

    # 任务1：爬取新闻列表页，提取详情页URL（上游任务）
    def crawl_list_page(**kwargs):
        """爬取列表页，提取URL，存入XCom（Airflow任务间数据传递）"""
        list_url = "https://xxx.com/news/list"
        response = requests.get(list_url, timeout=10)
        soup = BeautifulSoup(response.text, "lxml")
        
        # 提取详情页URL
        detail_urls = [a["href"] for a in soup.find_all("a", class_="news-link")]
        
        # 将URL存入XCom，供下游任务使用
        kwargs["ti"].xcom_push(key="detail_urls", value=detail_urls)
        print(f"提取详情页URL：{len(detail_urls)}条")

    # 任务2：分布式爬取新闻详情页（下游任务，依赖任务1）
    def crawl_detail_page(**kwargs):
        """从XCom获取URL，批量爬取详情页"""
        # 从XCom获取上游任务传递的URL
        detail_urls = kwargs["ti"].xcom_pull(key="detail_urls", task_ids="crawl_list_page")
        
        # 爬取详情页（真实场景中可结合Celery实现分布式爬取）
        results = []
        session = requests.Session()
        session.headers = {
            "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
        }
        
        for url in detail_urls:
            try:
                response = session.get(url, timeout=10)
                response.raise_for_status()
                soup = BeautifulSoup(response.text, "lxml")
                
                title = soup.find("h1", class_="title").get_text(strip=True)
                content = "".join([p.get_text(strip=True) for p in soup.find_all("p", class_="content")])
                publish_time = soup.find("span", class_="publish-time").get_text(strip=True)
                
                results.append({
                    "url": url,
                    "title": title,
                    "content": content,
                    "publish_time": publish_time
                })
            except Exception as e:
                print(f"URL: {url} 爬取失败，原因：{str(e)}")
        
        # 将结果存入CSV（真实场景中可存入数据库）
        df = pd.DataFrame(results)
        df.to_csv("/data/crawler/news_detail.csv", index=False, encoding="utf-8")
        print(f"详情页爬取完成，成功{len(results)}条")

    # 定义任务（PythonOperator，执行Python函数）
    task1 = PythonOperator(
        task_id="crawl_list_page",
        python_callable=crawl_list_page,
        provide_context=True,
    )

    task2 = PythonOperator(
        task_id="crawl_detail_page",
        python_callable=crawl_detail_page,
        provide_context=True,
        executor_config={"cpus": 2, "memory": "2G"},  # 配置单个任务的资源
    )

    # 定义任务依赖：task1执行完成后，再执行task2
    task1 >> task2

# 3. 启动Airflow集群（分布式部署）
# 1. 启动PostgreSQL（存储Airflow元数据）
# 2. 启动RabbitMQ（Celery Broker）
# 3. 启动Airflow WebServer（可视化界面）
# nohup airflow webserver -p 8080 > /data/airflow/logs/webserver.log 2>&1 &
# 4. 启动Airflow Scheduler（调度器）
# nohup airflow scheduler > /data/airflow/logs/scheduler.log 2>&1 &
# 5. 启动Celery Worker（分布式执行节点）
# nohup airflow celery worker > /data/airflow/logs/worker.log 2>&1 &

实战体验与踩坑记录（核心重点）

• 优点：调度能力极强，支持复杂任务依赖（如列表页→详情页爬取）、定时调度、手动触发，适合多源异构爬虫；自带可视化Web界面，可直观查看任务执行状态、调试任务、配置告警；支持Celery Executor，可实现任务分布式执行，兼顾调度和性能；企业级支持完善，适合大规模、精细化管控的爬虫场景。
• 踩坑点1：重量级部署——Airflow需要依赖PostgreSQL（元数据存储）、RabbitMQ（Celery Broker），部署复杂度远高于Celery、Ray，中小团队运维压力大；
• 踩坑点2：任务调度延迟——当日均任务量超过50万条，Airflow的调度器会出现延迟（核心精力放在依赖管理上，而非高并发调度）；
• 踩坑点3：XCom数据传递限制——任务间通过XCom传递数据（如URL列表），当数据量过大（超过100MB），会导致XCom卡顿、任务失败，需改用数据库/文件传递数据；
• 局限性：轻量级、无复杂依赖的爬虫场景，用Airflow显得冗余，学习、运维成本过高；纯爬虫场景下，性能不如Ray，并发能力不如Celery（需结合Celery才能提升并发）。

三、三种方案全方位实战对比（核心选型依据）

结合前面的实战解析，我们从“爬虫适配性”“性能”“运维”等7个核心维度，做全方位对比（数据均来自实战实测，非理论值），帮你快速选型：

对比维度	Celery	Ray	Apache Airflow
核心定位	分布式任务队列	分布式计算框架	分布式任务调度平台
爬虫适配性	中小规模、无复杂依赖爬虫（首选）	大规模、高吞吐、有状态爬虫（首选）	多源异构、复杂依赖爬虫（首选）
并发性能（实测）	单集群≤20节点，日均≤100万条	单集群≥100节点，日均≤1000万条	单集群≤50节点，日均≤50万条（需结合Celery）
容错能力	中等（任务重试、节点故障重试）	高（节点宕机自动切换、Actor重启）	高（任务重试、依赖重试、失败告警）
学习成本	低（Python开发者1-2天上手）	中高（1-2周学习，理解Actor/Task模型）	高（2-3周学习，掌握DAG、Executor配置）
运维成本	低（部署简单，监控简单）	中（集群配置、资源管控复杂）	高（多组件依赖，运维压力大）
核心优势	轻量、易用、生态成熟	高性能、高可扩展、有状态适配	复杂依赖调度、可视化管控、定时灵活
核心劣势	大规模调度效率低，无复杂依赖支持	生态不完善，轻量场景冗余	重量级、性能一般，纯爬虫场景冗余
实战选型建议	个人项目、中小团队、数据量不大	企业级大规模爬虫、高吞吐需求	企业级多源爬虫、复杂依赖调度需求

补充说明（实战重点）

1. 不要盲目追新：Ray性能强，但中小规模爬虫用Celery足够，无需为了“高大上”切换到Ray，增加运维成本；
2. 组合使用场景：Airflow + Celery 可实现“复杂调度+高并发执行”，适配多源高吞吐爬虫（如企业级舆情爬虫）；Ray + Airflow 可实现“大规模计算+精细化调度”，适配超大规模复杂爬虫；
3. 避坑核心：选型前先明确自身需求——数据量、节点数、是否有复杂依赖、团队技术栈，再对应选择，而非单纯对比性能。

四、实战选型指南（直接套用，避免踩坑）

结合5年分布式爬虫落地经验，总结4种常见场景的选型方案，直接套用即可：

场景1：个人项目、小团队，日均≤10万条数据

• 选型：Celery + Redis（Broker）
• 理由：部署最简单、学习成本最低，Python开发者快速上手，无需复杂运维，足够支撑需求；
• 优化建议：用RabbitMQ替代Redis做Broker，避免任务堆积（数据量超过10万条时）。

场景2：中小团队，日均10-100万条数据，无复杂依赖

• 选型：Celery + RabbitMQ（Broker）
• 理由：兼顾易用性和性能，支持20节点以内集群，运维简单，成本低；
• 优化建议：自定义Worker调度策略，解决负载不均问题；配置任务结果定时清理，避免Backend堆积。

场景3：企业级，日均100-1000万条数据，高吞吐、有状态

• 选型：Ray 集群
• 理由：性能最强，支持大规模节点，有状态爬取（复用会话、代理池）效率高，自带可视化监控；
• 优化建议：合理配置Actor资源（CPU/内存），及时将任务结果写入HDFS/MongoDB，释放Object Store内存。

场景4：企业级，多源爬虫（新闻、电商、社交），有复杂依赖

• 选型：Airflow + Celery + RabbitMQ
• 理由：Airflow负责复杂依赖调度、定时执行、可视化管控，Celery负责高并发执行，兼顾调度和性能；
• 优化建议：不用XCom传递大量数据，改用MongoDB存储中间数据（如URL列表）；配置任务资源限制，避免节点过载。

五、实战踩坑汇总（所有坑均来自真实项目，必看）

Celery 常见踩坑

1. Broker选型错误：Redis适合小数据量，大数据量必须用RabbitMQ，否则会出现任务堆积、调度延迟；
2. 任务结果堆积：Backend存储任务结果后，需定时清理（如用定时脚本删除7天前的结果），避免占用过多内存；
3. Worker负载不均：默认round-robin调度策略不适合爬虫任务，需自定义调度策略（如按Worker节点当前任务数分发）。

Ray 常见踩坑

1. 资源配置不当：Actor/Task未限制CPU/内存，导致节点资源耗尽宕机，需在初始化时明确配置资源；
2. 结果存储压力：千万级任务结果存入Object Store，导致内存溢出，需及时写入外部存储（HDFS/MongoDB）；
3. 调试困难：Ray的分布式调试不如本地调试方便，需用Ray Dashboard查看任务日志，定位问题。

Apache Airflow 常见踩坑

1. 多组件依赖部署错误：PostgreSQL、RabbitMQ、Airflow版本不兼容，导致集群启动失败，需严格匹配版本（如Airflow 2.6 + PostgreSQL 14 + RabbitMQ 3.12）；
2. XCom数据量过大：任务间传递大量数据（如百万级URL），导致XCom卡顿，需改用数据库存储中间数据；
3. 调度延迟：调度器资源不足，导致任务延迟执行，需给调度器分配足够的CPU/内存（建议≥4核8G）。

六、总结（核心观点，无空洞套话）

分布式爬虫选型，核心是“适配需求”，而非“追求最优性能”。Celery、Ray、Apache Airflow 三种方案，没有绝对的好坏，只有是否适合自己。

• 轻量、简单、数据量小 → 选Celery，省心省力；
• 大规模、高吞吐、有状态 → 选Ray，性能为王；
• 多源、复杂依赖、精细化管控 → 选Airflow，调度为王；
• 复杂场景（多源+高吞吐） → 组合使用（Airflow + Celery / Ray）。

最后提醒一句：分布式爬虫的核心是“稳定爬取、高效执行”，框架只是工具，选型后做好优化（反反爬、资源管控、容错兜底），比盲目切换框架更重要。