1. 项目概述浏览器集群爬虫系统是什么解决什么问题Browser Cluster浏览器自动化集群爬虫系统说白了就是把一堆浏览器实例像军团一样组织起来统一调度、统一分配任务实现大规模网页采集、自动化操作和内容提取。它和传统爬虫最大的区别在于传统爬虫用 HTTP 请求库直接抓 HTML遇到需要执行 JavaScript 的页面、需要模拟真实用户操作的流程就束手无策而 Browser Cluster 是用真实浏览器内核渲染页面天然适应现代前端技术栈能正确处理异步加载、动态渲染、复杂的用户交互比如点击、滚动、登录、表单提交这些操作。这个系统解决的问题很明确单机浏览器实例能开有限并发一高就会被网站拦截或者因为资源耗尽直接崩溃。浏览器自动化单点跑通容易但要稳定跑上几十上百个实例、跨多台机器、持续运行、还要不互相干扰是个典型的工程化问题。我最初接触这类需求是因为某个模拟项目里需要采集大量动态渲染的页面数据用请求库根本拿不到渲染后的 DOM爬虫要么卡在等待上要么被反爬策略盯上。而 Browser Cluster 这套思路在最基础的形式下就是把 Playwright 或 Puppeteer 驱动的 Chromium 实例池化用队列接收任务拿一个空闲浏览器处理一个任务处理完再收回来。适合谁看这篇内容第一类是做数据采集但还没搞定复杂页面的人第二类是已经写完了单机爬虫、想在并发和稳定性上做提升的开发者第三类是对分布式任务调度感兴趣的工程人员。这套系统的设计思路不仅适用于爬虫也很适合做自动化测试任务分发、批量网页截图、定时巡检等场景核心思想完全是相通的。下面我就把从单机浏览器脚本到一套小型浏览器集群的完整搭建过程、核心架构、踩过的坑全部铺开讲一遍。2. 架构设计与技术选型为什么是 Playwright、Redis 和多节点2.1 浏览器自动化方案选型浏览器自动化方案早年基本是 Selenium 的天下但我在实际对比后这套系统用了 Playwright。原因很具体多 context 的浏览器上下文隔离能力省掉了很多造轮子的工作每个任务可以开一个独立的 context相当于一个隔离的浏览环境Cookie、缓存、localStorage 完全不共享。另外 Playwright 的自动等待做得相当扎实locator 会自动等待元素出现、可交互不用像 Selenium 那样靠死等或者自己写轮询。Puppeteer 也是个好选择生态成熟但它的默认 API 风格是偏底层的很多便利功能需要封装。Playwright 是后来者跨浏览器统一 API而且内置了 BrowserContext 隔离、更精细的权限控制、更好的移动端模拟支持。可能有人担心 Playwright 的文档没有 Puppeteer 多但实际用下来它在社区热度已经很高文档质量也不错问题答案基本都能搜到。关于无头模式Chromium 的 new headless 模式已经可以和 headful 模式保持一致的表现关闭了 WebDriver 标志位之后被检测的概率也降低不少。值得注意的是别单纯为了省资源就用老的 headless 模式很多反爬脚本容易从 UA、渲染行为这些细节上识别出异常。建议直接 option 里设置channelchromium或使用默认的 Chromium然后用headlessTrue的 new headlessPlaywright 默认就是新的稳定性更好。2.2 任务队列选型为什么是 Redis Stream 而不是 Celery任务分发是整个集群的大脑。最初我考虑直接用 RabbitMQ 或者 Redis List后来选择了 Redis Stream。原因有几点Redis Stream 天然支持消费者组Consumer Group每条消息可以被多个消费者竞争消费但不会重复被同一个组内的多个消费者拿到这正好符合多 worker 抢任务的场景。另一个关键是消息确认机制XACK任务处理失败后可以不确认让消息重新进入 PELPending Entries List其他 worker 可以认领重新处理这给失败重试提供了基础。如果用 Redis List 做队列就需要自己维护任务在途状态、失败回滚这些逻辑安全和可靠性都要自己搞。用 Celery 则有点重它默认的分发机制对短生命周期任务很合适但如果任务是控制远程浏览器实例执行任务状态和浏览器实例状态需要更精细的管理Celery 的抽象反而碍事。我用 Redis 的另一个原因是边角功能多可以用 Hash 维护浏览器节点的状态、存活心跳用 Sorted Set 做定时任务的延时队列比如任务失败后 30 秒重试。一套基础设施就能解决调度、状态、重试三个问题不用在项目里引入三套中间件。2.3 集群调度策略整个集群的节点分两类角色调度器和 worker。调度器只负责接收任务、写入队列、管理失败重试worker 注册到调度器后各自去队列里抢任务然后驱动浏览器执行。不需要单独的 orchestrator 去主动下发任务到某个节点而是 worker 自己来拉取push/pull 模式这种模式的好处是天然去中心化新增一个 worker 不需要改动调度器配置自动负载均衡。worker 节点和浏览器的关系是 1:N。每一个 worker 内部维护一个浏览器池预启动几个浏览器实例待命。任务进来后从池子里拿出一个空闲浏览器新建一个 context把任务塞进去执行执行完关闭 context把浏览器放回池子。这里有个关键设计浏览器实例不销毁复用的只是创建和销毁 context。因为浏览器实例每次新建要占几百兆内存、加载资源代价不小而 context 的新建销毁成本要低很多。调度器还会记录每个 worker 的“健康状态”和“当前负载”用 Redis 的 Hash 结构存心跳时间和上报的负载指标。新任务写入后如果某个 worker 连续几次心跳超时调度器就把分配给它的任务标记为可重试重新放回队列。3. 核心模块与关键实现浏览器池、任务生命周期、反检测配置3.1 浏览器池的初始化与管理我先说浏览器池的初始化因为这是最容易被人忽视但极端影响稳定性的模块。我的实现思路是这样# browser_pool.py import asyncio from playwright.async_api import async_playwright class BrowserPool: def __init__(self, max_browsers4): self.max_browsers max_browsers self.idle_browsers [] self.running_tasks {} self.playwright None async def start(self): self.playwright await async_playwright().start() async def acquire(self): if self.idle_browsers: browser self.idle_browsers.pop() elif len(self.running_tasks) self.max_browsers: browser await self.launch_browser() else: # 等一个空闲浏览器释放 while not self.idle_browsers: await asyncio.sleep(0.2) browser self.idle_browsers.pop() return browser async def launch_browser(self): browser await self.playwright.chromium.launch( headlessTrue, args[ --disable-dev-shm-usage, --no-sandbox, --disable-blink-featuresAutomationControlled, ] ) return browser async def release(self, browser): self.idle_browsers.append(browser)这段代码看起来简单但有几个细节必须说明。--disable-dev-shm-usage不加上容器环境里/dev/shm只有 64MB多个页面一渲染就直接崩--disable-blink-featuresAutomationControlled可以去掉部分自动化控制特征--no-sandbox在 Docker 环境是必须的但在本机调试不要加否则有安全风险。池子的核心调度逻辑是 acquire 和 release。acquire 优先复用空闲浏览器没有空闲再去判断能不能新开。这里的max_browsers要根据机器内存和 CPU 合理设置。我大概估算过一个 Chrome 页面进程在空白页状态下占用 30-50MB打开一个中型电商页面后轻松到 200-400MB。所以一台 8GB 内存的机器最多开 4-5 个浏览器实例比较合理再往上开系统开始交换内存任务反而变慢。release 的时候要注意浏览器本身有没有崩。如果页面崩溃、连接断开这时的 browser 对象已经不可用了单纯放回池子会导致后续任务拿到一个坏连接。我是这样处理的async def release(self, browser): try: contexts browser.contexts # 如果 context 计数异常说明浏览器可能已经挂了 if browser.is_connected(): self.idle_browsers.append(browser) else: await browser.close() except Exception: # 浏览器已经死了丢弃让 pool 重新拉起 pass在实际运行中浏览器实例莫名其妙的崩溃很常见尤其是内存压力大的时候。所以池子还必须有一个主动清理和重建机制每隔一段时间巡检 idle 列表里的浏览器如果空闲超过 60 秒就给它关闭整体水位调低当任务量上来后再逐步补充。这一步很重要不然高负载后任务回落还保留一堆空闲浏览器白白吃内存。3.2 任务生命周期管理我在系统里给每个任务定义了五个状态等待中、执行中、成功、失败、已重试。这五个状态都在 Redis 里维护调度器和 worker 之间通过约定好的 key 前缀来协同。任务的生命周期是这样流转的调度器接收外部请求生成一个唯一任务 IDUUID把任务详情 JSON 序列化后XADD到 Stream 队列。worker 从 Stream 读取任务先把任务状态改成执行中然后去池子里 acquire 一个浏览器在浏览器里新建 context绑定页面路由和任务处理函数执行采集执行完了写入结果到 Redis 或文件存储关闭 contextrelease 浏览器最后 XACK 消息确认。这里面最大的坑在于Stream 消息确认不能过早。如果 worker 一读到消息就 XACK执行过程中浏览器崩了、任务失败这条消息就再也找不回来了。正确做法是任务全部执行完成、结果已经落盘之后再 XACK。如果任务执行中 worker 进程崩溃了它读取但未确认的消息会留在 PEL 里调度器巡检时可以检测出超时未确认的消息重新投递到另一个 worker。另一条要注意的点是任务超时控制。浏览器自动化任务最怕的就是页面加载卡死一个任务跑几十分钟不结束。我给每个任务设置了一个最长执行时间比如 60 秒到点还没完成就强杀这个 context任务标记失败进入重试队列。超时时间不能设太短否则碰到网络慢的页面经常误杀也不能太长否则集群吞吐量被卡死的任务拖垮。我的经验是按照目标站点的平均加载时间乘以 3 再补 10 秒余量。比如目标站点平均 3 秒加载完超时就是 19 秒保险一点设 20-30 秒。3.3 反检测与浏览器指纹配置浏览器自动化被目标网站识别核心识别点无非是几个navigator.webdriver属性是否为 true、自动化控制标志是否开启、浏览器指纹是否和真实设备一致、行为模式是否自然。我在这套系统里做了四层配置处理第一层是启动参数。如下browser await playwright.chromium.launch( headlessTrue, args[ --disable-dev-shm-usage, --no-sandbox, --disable-blink-featuresAutomationControlled, --disable-featuresIsolateOrigins,site-per-process, ] )--disable-blink-featuresAutomationControlled是去掉navigator.webdriver true的常见手段在 Chromium 系里最有效。不过现在很多站点还会检测别的比如 window.chrome 对象是否为空壳、WebGL 渲染器信息等。第二层是 context 级别注入。用 Playwright 的add_init_script在页面初始化脚本开始前改写 JS 对象context await browser.new_context( viewport{width: 1920, height: 1080}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, localezh-CN, timezone_idAsia/Shanghai, ) await context.add_init_script( Object.defineProperty(navigator, webdriver, {get: () undefined}); Object.defineProperty(navigator, languages, {get: () [zh-CN, zh]}); Object.defineProperty(navigator, plugins, {get: () [1, 2, 3, 4, 5]}); )这里要小心user_agent必须和真实浏览器保持一致。如果 Playwright 默认的 UA 里带着 HeadlessChrome 字样伪装再多数值也没用。我的做法是在真实浏览器里抓一个完整的 UA 字符串直接复制过来用。第三层是行为模拟。采集任务尽量模拟真实用户的操作节奏滚动页面的速度不要太均匀点击按钮前稍微停留鼠标移动轨迹可以加一点小幅度抖动。这一层是纯体验优化对于追求速度的任务可以省略但如果目标站点反爬严格这一步就是必选项。第四层是 IP 轮换。浏览器集群并发大如果出口 IP 都是同一个特征太明显。我在 worker 启动时给每个浏览器配置一个代理 IPHTTP/HTTPS 代理并且定期更换。代理池的维护不展开讲核心思路是调度器从代理池模块拿一个可用代理配到 context 的proxy参数里任务执行完回收检测可用性后再放回池子。有一点必须提醒反检测措施永远是猫鼠游戏。本篇内容只讨论用户代理与浏览器指纹配置的通用做法不针对任何具体网站做绕过性质的教学。做爬虫采集业务一定要先评估目标网站的服务条款和数据版权要求合规是底线。4. 从单机到多节点的实操过程搭建 Browser Cluster 的完整步骤4.1 环境准备与基础目录结构这套系统我用的是 Python 3.10 Playwright。依赖安装很简单pip install playwright playwright install chromium我的项目目录结构是这么组织的browser_cluster/ ├── scheduler/ │ ├── main.py # 调度器入口接收任务写入队列 │ ├── task_queue.py # Redis Stream 封装 │ └── retry.py # 超时重试和失败重试逻辑 ├── worker/ │ ├── worker.py # worker 启动入口 │ ├── browser_pool.py # 浏览器池管理 │ ├── task_handler.py # 任务处理分发 │ └── extractor.py # 页面数据提取逻辑 ├── common/ │ ├── redis_client.py # Redis 连接封装 │ ├── config.py # 配置项 │ └── logger.py # 日志 └── scripts/ ├── add_task.py # 手动投递任务的脚本 └── health_check.py # 集群状态检查这样一个结构scheduler 和 worker 可以部署在不同的机器上也可以部署在同一台机器上多个进程。我最初的测试环境就是一台 8GB 内存的服务器同时跑一个 scheduler 进程和两个 worker 进程每个 worker 最多开 3 个浏览器实例。4.2 Redis Stream 队列封装任务队列模块是调度器侧的核心代码。我直接封装了 Redis Stream 的常用操作# task_queue.py import redis import json class TaskQueue: def __init__(self, redis_url, stream_keybrowser_cluster:queue): self.r redis.from_url(redis_url, decode_responsesTrue) self.stream_key stream_key def push_task(self, task_dict): # XADD 自动生成消息 ID消息体是 JSON 序列化后的任务 task_id task_dict.get(task_id) return self.r.xadd(self.stream_key, {payload: json.dumps(task_dict)}, id*) def claim_timeout_tasks(self, group_name, min_idle_ms60000): # 扫描超时未 ACK 的消息重新放入队列 pending self.r.xautoclaim(self.stream_key, group_name, self._get_consumer(), min_idle_msmin_idle_ms) return pendingxautoclaim命令是 Redis Stream 用来重新分配超时消息的指定命令。它会把某个消费者组中空闲时间超过阈值的 pending 消息转移给其他消费者避免一个 worker 挂掉后任务永远卡在 PEL 里。还有一个容易忽略的点消费者组必须先创建worker 才能消费消息我是在 worker 启动时调用xgroup_create的。投递任务时的字段格式我定义为{ task_id: uuid-uuid-uuid, urls: [https://example.com/page1], extract: {type: list, selector: .item a}, max_retries: 3, timeout: 30000 }timeout是任务最大执行毫秒数worker 端执行这个任务时会传给 context 的页面加载逻辑。这里要特别注意不要直接把整个采集策略都塞进消息体里。消息体过大Redis 序列化和网络传输开销大应该传任务类型和参数引用真正的采集配置放在调度器和 worker 共用的配置文件里数据库里存一份配置表也行。我的经验是用配置文件加数据库配置表结合消息体里只放 task_type、目标链接和必要的参数覆盖这样配置更新不需要重启 worker。4.3 Worker 主逻辑与任务执行循环Worker 启动后会做三件事连接 Redis 并创建消费者组、启动浏览器池预热、进入消费循环。核心代码如下# worker.py import asyncio from common.redis_client import get_redis from worker.browser_pool import BrowserPool from worker.task_handler import handle_task GROUP_NAME browser_cluster:workers async def process_loop(): r get_redis() pool BrowserPool(max_browsers4) await pool.start() # 预热浏览器 await pool.preheat() consumer_name fworker_{r.client_id()} stream_key browser_cluster:queue # 确保消费者组存在 try: r.xgroup_create(stream_key, GROUP_NAME, id0, mkstreamTrue) except Exception as e: # 已存在的异常忽略 pass while True: # 阻塞读取最多等 5 秒 resp r.xreadgroup( GROUP_NAME, consumer_name, {stream_key: }, count1, block5000, ) if not resp: # 没有新任务巡检一下池子里的浏览器状态 await pool.maintenance() await asyncio.sleep(0.5) continue for _, messages in resp: for msg_id, data in messages: task json.loads(data[payload]) browser await pool.acquire() try: result await handle_task(task, browser) store_result(task[task_id], result) r.xack(stream_key, GROUP_NAME, msg_id) except Exception as e: log_exception(task[task_id], e) if task.get(max_retries, 1) 0: retry_task(task) finally: await pool.release(browser)这里有一个细节值得注意xreadgroup的count1表示一次只取一条消息。多 worker 并行时每个 worker 一次拿一条任务后立刻处理处理完再回来拿下一个。如果一次拿太多条处理不过来这些消息会处在 pending 状态万一 worker 挂了消息要等超时后才能被其他 worker 抢走造成吞吐波动。pool.preheat()是启动时预先创建两个浏览器实例。这个预热操作很关键没有预热第一批任务要等浏览器冷启动每个任务多等 3-5 秒预热后任务来了直接取现成浏览器速度快很多。但也不要预热太多否则流量稀疏的时候白白占内存。4.4 结果存储与数据管线任务采集完成后的结果我一开始直接写到 Redis 的 String 类型里key 为task_result:{task_id}。后来数据量大了之后这种方式的危害就暴露出来String 类型没有过期语义做批量清理很麻烦而且结果有嵌套结构靠 JSON 序列化存入读出填加字段成本也不低。后来改成了双写策略小结果、需要即时查询的写 Redis Hash大批量原始数据写本地文件或对象存储。整个链路比较简单worker 里抽取完数据调store_result把数据写入存储层。面向数据量大的场景建议在存储结果之前先做一层去重。我在 extractor 层记录一个内容指纹对关键字段做 hash相同指纹的结果如果已经存在直接标记为重复不重复写入。这一步能省掉下游很大一部分清洗成本。4.5 调度器与健康检查调度器的主循环是独立进程主要做三件事接收外部 API 请求创建任务扫描超时未确认的消息并重投递定期检查 worker 心跳并回收失联 worker 的可重试任务。worker 的心跳上报我放在 process_loop 里每五秒执行一次。具体做法把 worker 启动时间、当前存活浏览器数、空闲浏览器数、当前任务队列长度写入 Redis 的 Hashdef heartbeat(): current_load { worker_id: worker_id, started_at: started_at, alive: True, load: len(running_tasks), capacity: pool.max_browsers, last_seen: int(time.time() * 1000), } r.hset(browser_cluster:workers, worker_id, json.dumps(current_load))调度器的健康检查模块可以读取这些心跳展示整个集群的状态。我提供了一个简单的命令行脚本python scripts/health_check.py输出大致长这样Worker ID Status Browsers Load Last Seen worker_48a ALIVE 4/4 2 1s ago worker_0e37 ALIVE 3/3 1 2s ago worker_c21 DEAD - - 3 min ago如果某个 worker 超过 30 秒没有更新 last_seen调度器就把它标记为 DEAD。DEAD worker 拥有但未确认的任务调度器会扫描它们的 PEL 列表把它们重新投递到 Stream让其他 worker 接手。4.6 失败重试与退避策略失败重试看起来简单失败了再投一次。但什么都不想直接重试会把目标站点和自身集群都搞垮。我的重试策略是带退避的规则如下第一次失败后立即重试。第二次失败等 1 秒再投递。第三次失败等 10 秒再投递。超过最大重试次数标记为永久失败进入死信队列。这里我用了 Redis Sorted Set 实现延时队列。任务需要延时重试时score 设置为当前时间加上延时秒数调度器每隔一秒取 score 小于当前时间的任务重新投递。这个设计比单纯 sleep 更稳worker 进程不用挂在那里等任务交接给调度器worker 可以立刻去处理下一个任务。5. 实战运行数据与性能表现5.1 单机三节点压力测试我在测试环境跑了一轮基础压测一个 scheduler、两个 worker、单机部署每个 worker 最多 3 个浏览器实例总共 6 个浏览器并发。目标是用脚本模拟一个数据列表页的采集每页大约 2 秒加载完成。结果显示吞吐大约是每秒 2.5 个任务左右。单个任务从入队到结果返回平均耗时约 3.2 秒。这个数据看起来不高但要做到的是稳定性和并发扩展性浏览器渲染页面毕竟不是纯 API 请求不用拿它和 Scrapy 比吞吐量。以稳定性为优先的场景这个成绩完全够用。我又加了一个 worker也是 3 个浏览器实例总浏览器数变成 9 个吞吐量升到了每秒 3.6 个。接近线性扩展说明瓶颈不在调度器在浏览器本身的并发能力上。再多加浏览器实例单机内存开始吃紧任务响应时间反而变慢。5.2 内存与监控指标我实时监控了 worker 进程的内存变化。单个浏览器实例在长时间运行后内存会缓慢上涨Playwright 的浏览器实例释放 context 时不是所有内存都能立刻归还给操作系统。这是 Chromium 的常见行为。如果不做定时回收跑几个小时后内存水位会高得吓人。我的处理方式是空闲浏览器定期巡检空闲超过 60 秒的直接关闭并新建替代。活跃浏览器连续处理完 100 个任务后强制关闭重建一次防止长时间累积内存碎片。整个 worker 进程的内存一旦超过设定阈值比如 4GB触发毛细血管级别的清理把 idle 列表全部清空重新拉起。这一套做下来连续运行 24 小时内存波动都在可控范围内没有出现过 OOM。5.3 异常场景目标站点响应变慢压测中途我故意断掉了目标站点的网络模拟超时场景。现象是大量任务进入 PEL 等待确认由于超时机制的存在这些消息在 30 秒后会被重新投递然后又被其他 worker 抢走再次超时。这会导致重试风暴——所有 worker 都在反复处理同一个注定失败的任务。这里我踩过一次坑之后增加了一个熔断机制如果某个任务的失败次数在短时间内快速上升调度器直接把任务标记为 PENDING_DEAD 状态不再投递等待外部人工介入检查目标站点是否恢复。另外还按目标域名做了分桶统计如果某个域名在最近 5 分钟内的失败率超过 30%就不要再给这个域名的任务投递了先放冷一段时间。实践下来效果很好如期避免了大面积任务堆积。6. 常见问题与排查技巧实录6.1 僵尸任务消息被重复消费问题表现同一个任务被多个 worker 同时执行。这是我最先遇到的问题。原因是 worker 处理完任务后XACK 还没执行进程就崩溃了或者任务执行耗时超过了 Redis 认为的 idle 时间。消息重新排队后另一个 worker 又抢到。如果这个任务本身不是幂等的比如同一个表单重复提交就会造成脏数据。排查思路看 Redis Stream 的 PEL 列表xpending browser_cluster:queue browser_cluster:workers如果看到大量消息长期没有 ACK就说明 worker 端处理逻辑有异常。解决方式是让任务处理函数本身设计成幂等写结果之前先查一下 task_id 是否处理过处理过就跳过。我的任务处理器里有一个已处理任务 ID 的布隆过滤器几百万任务的重复判断只在微秒级别。6.2 浏览器实例泄漏导致内存暴涨问题表现worker 运行数小时后内存从 1GB 涨到 6GB然后 OOM。排查发现两个原因一是 handle_task 里打开了 context 和 page但异常分支没有执行await context.close()导致 context 没有关闭二是浏览器池的 release 逻辑里浏览器已经被异常退出但池子没有正确重建。我后来在任务处理函数外面包了一层async with风格的 context 管理确保无论正常还是异常context 都会关闭# task_handler.py async def handle_task(task, browser): context await browser.new_context( user_agenttask.get(ua, DEFAULT_UA), viewport{width: 1920, height: 1080}, proxytask.get(proxy), ) try: page context.pages[0] if context.pages else await context.new_page() # 执行采集 return result finally: await context.close()这种写法的好处是异常也会触发 close不会留漏网的 context。但要注意context.close()是异步的且要等待资源释放如果任务处理时间短但非常频繁close 本身也会占用不少时间。这种情况下可以考虑复用 context每隔一定数量或时间重建。6.3 页面筛选器失效元素等待策略页面自动化最烦人的问题就是元素定位时有时无。这里的核心是等待策略。Playwright 的 locator 自带一些自动等待但很多人会犯一个错误拿到片段后直接page.locator(...).inner_text()如果元素还在加载就会等直到超时抛出异常。而任务执行次数一多这种等待超时会显著拖慢整体吞吐。我的经验是页面加载出来的初始状态先等一个关键节点元素再执行后续操作。还要区分“加载要等”“渲染要等”“交互后异步刷新要等”三种情况加载等待用page.goto(url, wait_untildomcontentloaded)不要默认等 networkidle有些页面持续有网络请求等 networkidle 要等到猴年马月。渲染等待用 locator 的wait_for(statevisible)配合自定义超时时间。交互后异步刷新优先用expect_response()拦截接口响应没有接口可观察时再考虑固定 sleep。这里单独说一下 sleep。很多人习惯await page.wait_for_timeout(2000)硬等这在自动化里是万不得已的手段。硬等 2 秒相当于在同一时刻并发窗口的吞吐量被百分比拉低。尽可能用事件驱动替代 sleep比如等待某个元素出现、等待某个请求完成、等待某个文本变化。6.4 Redis 队列消息被清空或丢失Redis Stream 的消息会默认保留在内存里除非被显式删除这会导致 Redis 内存上涨。我一开始没设置过期的策略跑了一周发现 Redis 内存占用几个 GB其中大部分是历史消息残留。正确做法是设置 Stream 的最大长度r.xadd(stream_key, {payload: json.dumps(task_dict)}, id*, maxlen50000, approximateTrue)maxlen50000表示队列最多保留 5 万条消息超过后自动清理最旧的。如果任务量很大调大一点但要注意不能设太小否则 PEL 里的消息可能直接被截断重试逻辑会因为消息不存在而失效。还要记得给 Stream 设置一个合理的 TTL 或者定期清理。6.5 多个 worker 时日志混在一起排查困难多 worker 并行时日志会交错输出一个问题要翻半天才能从几万行日志里找到相关记录。我的优化方案是统一日志格式包含 task_id、worker_id 和一个自定义 trace_id。每个任务在开始时生成一个 trace_id全程贯穿该任务的所有日志、异常、执行步骤。这样排查某个任务时直接按 trace_id grep 就能把整个生命周期还原出来效率提升非常大。6.6 站点反爬识别与浏览器指纹修补这一条是爬虫世界的永恒话题。之前提到过用 add_init_script 注入 JS但只有这一个还远远不够。有些反爬方案会检查navigator.hardwareConcurrency、deviceMemory、WebGL renderer这些指纹数据。我建议采用以下思路来修补用 Playwright 的create_context参数把 viewport、UA、locale、timezone、permissions 都设置好不同任务用不同组合避免所有 worker 呈现完全一致的指纹。用中间件统一注入屏幕比例、显卡渲染器、内存等变量的覆盖逻辑。不要让每个 context 的特征完全一样要模拟一个真实环境“自然态”的分布比如有的窗口分辨率高一点有的低一点有的语言是 zh-CN有的语言是 zh-TW仅限合规场景评估。这些措施的核心是让自动化浏览器的特征从“一眼假”变成“看起来普通”但要清醒认识到这并非万无一失。合规采集才是长期可持续的出路。7. 经验总结与后续扩展方向我个人在实际操作中的体会是浏览器自动化集群爬虫系统最大的价值不是单机脚本的并发量翻了几倍而是把“浏览器自动化”从一次性脚本工程变成了可运营、可观测、可恢复的基础服务。调度、心跳、重试、熔断这套分布式里通用的基建一旦沉淀下来后续想扩什么场景都会很快。几个值得继续扩展的方向第一是任务调度的策略升级。现在的队列拉取模式是粗粒度的如果发现某些任务的目标 URL 所属站点响应速度很慢可以在调度器侧把该任务分配到独立的低并发队列隔离站点波动带来的影响。这就是点击率预估里的“站点分桶”对稳定性提升肉眼可见。第二是采集任务的断点续采。当前实现是每个任务独立执行如果目标数据列表有几万页一个 worker 撑不住。可以设计成分页抓取模式调度器把整个列表任务拆分为多个子任务每个子任务负责一个页区子任务完成后由调度器汇总。这样任意子任务失败都只影响一小部分重试成本也低。第三是数据清洗和链路监控。目前结果存储只是落盘后续如果接入 MySQL 或数据仓库可以在写入前增加字段校验、类型转换、重复去重产出更规整的数据。同时可以把任务的失败率、耗时曲线打成指标接入监控面板一眼看出整个集群的健康状态。第四是动态调度策略。当前支持按 worker 预配浏览器实例数但不同时段任务高峰不同。可以定时分析任务队列积压量动态调整 worker 进程数和池子水位最高峰时段多开几个浏览器低谷时段回收资源。这个用 K8s 或者 systemd 服务配合都能做但要注意启动和关闭浏览器本身也有时间成本动态伸缩的步长不能太小否则颠簸会很严重。最后再分享一个小技巧如果你只是做普通的自动化和数据采集不一定要上完整的 Redis Stream 和集群架构。一个小项目跑单机直接进程内维护一个 asyncio.Queue加上几个 worker task 就够了。引入分布式组件本身也有运维成本。我之所以最终选择 Redis Stream 这套框架是因为任务量起来了、需要多台机器协作、还需要可靠重试这时候“能用”和“好用”之间差距就完全体现出来了。做系统设计就是这样先定义清楚自己要解决到什么程度再选工具别让技术选型倒逼业务复杂度。