1. 从单机爬虫到集群调度：我为什么做这个系统
先交代一下背景。之前有段时间，我需要持续抓取一批网站的数据，量级不算特别大，但有几个特点让人头疼：目标站点分散、反爬策略各不相同、部分页面依赖浏览器渲染（典型的 SPA 应用，源码里拿不到有效内容）、单台机器跑久了 IP 和资源都吃紧。
一开始我的方案很朴素：一台服务器装上无头浏览器，写个定时任务挨个跑。结果跑了不到一个星期就出问题了。首先是稳定性，浏览器进程挂在无人值守的状态下，动不动就内存暴涨、僵尸进程越积越多，最后整个机器卡死。其次是效率，单机单浏览器的抓取速度有限，遇到对方网站响应慢一点，整个队列全堵住。最难受的是扩展性，想加一个目标站点，得手动改脚本、重新部署、盯着日志，完全谈不上“系统”。
后来我转变思路，决定做一个真正意义上的 Browser Cluster：把浏览器实例全部容器化，由中央调度器统一管理，爬虫任务按队列分发，每个节点独立运行、按需伸缩。这个项目前前后后改了三版，最终线上稳定跑了两个月，单日采集量比原来单机方案提升了七八倍，节点故障自愈率接近百分之百。
这篇文章我就把整套系统从架构设计到落地细节拆开讲一遍，包括容器编排方式、任务队列选型、浏览器会话复用、代理池管理、去重策略这些核心环节，以及我实际踩过的坑。适合已经写过爬虫、想往分布式方向走，或者正被浏览器渲染抓取困扰的开发者参考。
需要说明的是，这不算是零基础教程。如果你还不太清楚无头浏览器和普通 HTTP 请求的区别，建议先单独跑一个无头浏览器抓个页面熟悉一下，再回来看集群的编排逻辑会顺畅得多。
2. 架构设计：调度器、执行节点、队列与状态存储各自承担什么角色
整个系统的设计目标其实就三个：稳定、可扩展、易维护。我不需要多花哨的分布式理论，只要能把浏览器实例管好、把任务分配合理、把状态记录清楚，就足够了。基于这个原则，我把它拆成了四个核心模块：
2.1 中央调度器的职责边界
调度器是整个集群的大脑，但它做的事情被我刻意控制得很单一：接收任务、分配任务、记录任务状态、处理节点心跳。所有页面解析逻辑、数据清洗逻辑、反爬对抗逻辑，一律放在执行节点内部，调度器完全不关心。
这样设计的好处是故障隔离。调度器如果要去理解每个任务的具体业务，它就会成为性能瓶颈和稳定性短板。我见过不少人把调度器写成一个超级中心，既要管队列又要管解析又要管代理池，结果一挂全挂。我的做法是：调度器只维护任务元数据和节点状态，任务下发之后就不管过程了，只等节点上报结果。
2.2 执行节点的内部构成
执行节点就是真正跑无头浏览器的地方。每个节点启动一组 Docker 容器，容器内运行无头浏览器加上一个 worker 进程。worker 负责从队列拉取任务、调用浏览器执行页面操作、采集结果、回传状态。
这里有一个关键设计：节点本身是无状态的。所有需要持久化的东西，比如任务结果、抓取进度、去重记录，都放外部存储。节点任意时刻宕掉，调度器只需要把任务重新分配给别的节点就行。
2.3 任务队列：为什么最终选了 Redis Stream
队列选型我纠结过一段时间。市面上有各种消息队列方案，但对于这个场景，我的核心诉求就三条：支持任务优先级、支持延迟重试（应对临时封禁）、消费者端能方便地确认完成和超时重投。
最终我选了 Redis Stream，而不是一些重量级的 MQ。原因是集群规模本身可控，不需要复杂的分区和事务机制，而 Redis Stream 天然自带消费者组概念，ack 机制和待处理条目列表（pending entries list）非常契合“任务可能失败、需要重新投递”的场景。另外我们的集群状态存储用的也是 Redis，省掉一套中间件运维成本。吞吐量方面，单从 Redis Stream 消费任务，每秒处理几百个任务完全没压力，瓶颈只在浏览器渲染速度上。
2.4 状态存储与结果落地的方案
任务状态我用了一套简单的状态机：pending → running → success / failed / retrying。状态本身存在 Redis 里面，用哈希结构记录每个任务的当前状态和重试次数。数据落地分两路走：需要长期保存的采集结果写数据库（MySQL 或者 ClickHouse，看数据形态），只用于任务流转的临时状态全部留在 Redis，设置过期时间自动清理。
这套方案的好处是职责分明：Redis 管实时流转，数据库管最终产出。运行状态监控直接看 Redis 里的任务状态统计就能了解集群健康度，而不需要频繁查数据库。
3. 容器化浏览器节点的工程化细节
这是整个系统里坑最多的部分。表面上看，把无头浏览器装进 Docker 太简单了，无非就是写个 Dockerfile 而已。但真正跑起来才发现，浏览器进程在容器里的行为、资源限制的配置方式、镜像的体积控制，每一样都藏着一堆问题。
3.1 镜像构建：不要把所有东西塞进同一个镜像
我第一版镜像做得很粗暴：基础镜像里装了浏览器、装了 Python 环境、装了各种解析库，甚至把业务代码也打进去了。结果镜像体积直逼 3GB，每次更新代码重新构建镜像慢得要命，而且版本耦合严重——改一行爬虫逻辑也要重新拉一个几个 GB 的镜像到所有机器。
第二版我开始拆分：基础浏览器镜像（浏览器本体加运行库）单独构建，业务代码通过挂载目录的方式注入容器。这样基础镜像只更新浏览器大版本才需要重建，业务代码修改直接同步文件即可，省掉了漫长的镜像构建和分发时间。顺便提一句，浏览器镜像里我一个人工选择了独立安装 Chromium，而不是直接用现成的浏览器镜像，因为官方的极简镜像虽然体积小，但缺少很多字体和系统库，遇到渲染复杂页面时容易出诡异问题。
3.2 容器资源限制是最容易被忽略的稳定性命门
无头浏览器是个吃资源大户。我在测试环境里跑单容器没限制内存，一切正常；一上生产，三四个容器同时渲染复杂页面，直接触发系统 OOM，Docker 守护进程本身也被拖得不稳定。
后来我规定每个容器内存上限为 2GB，当容器内浏览器进程超过一定阈值时主动重启而不是等被系统杀。重启逻辑写在 worker 里：每执行完一个任务就检查浏览器进程的内存占用，超过设定值就杀掉，让下一个任务重启一个新实例。实测下来，主动重启比被动等待要稳定得多，整个集群的内存使用率也平稳了很多。
3.3 无头浏览器在容器内运行的必要参数
无头浏览器在容器里跑，有几个启动参数是必不可少的，缺一个都可能在特定场景下触发问题。以下是我最终稳定的参数组合：
- 禁用沙箱模式，因为容器内通常没有设置相关系统权限，开启反而会导致启动失败；
- 禁用共享内存，否则容器内默认的共享内存空间太小，多标签页场景容易崩溃；
- 设置窗口尺寸为固定的宽高，避免部分网站根据屏幕尺寸返回不同布局，影响元素定位；
- 禁用 GPU 加速，容器环境根本没有 GPU，开启反而增加不必要的开销。
还有一个细节容易被忽略：部分网站通过调用浏览器 API 检查真实用户浏览器环境，无头模式默认的特征容易被识别。这个属于反爬对抗范畴了，后面专门展开说。
4. 代理池组件的选型与调度策略
做集群爬虫，IP 问题迟早要面对。我不建议一开始就追求高强度的反检测，先把代理池的基础框架搭好，后续可以在池子的规模和频率控制上持续做精细化运营。
4.1 代理池的最小实现方案
代理池不需要做成一个独立的服务，完全可以和调度器共用一套 Redis。代理的来源有两种：买的代理服务商接口拉取，或者自建代理节点。不管是哪种来源，统一都在 Redis 里维护一个可用代理列表，记录代理的 IP、端口、协议类型、上次使用时间、失败次数这些字段。
调度器在分任务的时候不直接决定用哪个代理，而是把任务本身的属性（目标域名、所需地区等）告诉节点，节点在启动浏览器之前，先向 Redis 申请一个符合条件的代理。用完了之后，节点会回传一个“代理可用性反馈”，比如是否成功建立连接、是否出现验证码、是否出现 403，这些信号会被用来更新代理在池子里的权重。权重低的代理自然会被冷落甚至踢出池子。
4.2 代理与浏览器的绑定方式
有一个细节我一开始忽略了：代理必须在浏览器启动之前通过配置参数注入，而不是浏览器启动之后再用脚本设置代理。后者的方式只对 HTTP 请求生效，对 WebSocket 连接不生效，而且容易被网站通过浏览器的网络栈特征识别出代理痕迹。
正确做法是：在浏览器启动参数里直接指定代理服务器地址，这样浏览器所有流量包括 WebSocket、DNS 解析都会走代理通道，一致性最好。代价是每次切换代理都要重启浏览器，这个和会话管理策略是相冲突的，所以我最终采用了“绑定策略”：一个浏览器实例使用同一个代理直到它被回收，期间不再切换，避免频繁重启。
4.3 被反爬针对时的应急处理
如果某个节点反馈频繁出现验证码或者 403，我不会让这个节点继续硬碰。任务会被标记为延迟重试，重试间隔按照指数退避来设置，同时将该代理踢出保存一段时间，并让调度器减少该目标域名下并发任务的数量。
这套机制的实现成本很低，就是几个计数器和状态字段的事，但效果非常明显。整个集群跑下来，单站点的有效采集成功率能维持在较高水平，最关键的是因为我们有全局状态，所以能及时发现某个站点在策略收紧，而不至于等到封了大量代理才对目标源做调整。
5. 任务调度的核心实现：优先级、重试与动态扩容
任务调度逻辑是整个系统的灵魂。调度器不需要很“聪明”，但要把规则定清楚。
5.1 任务优先级与公平性
任务来源分两类：定时触发的一次性任务，以及持续运行的增量采集任务。一次性任务要求尽快执行，增量采集任务则按频率分散执行。为了避免低优先级的增量任务饿死或者反过来抢占太多资源，我设置了三级优先级：紧急、默认、后台。紧急任务插队执行，同一优先级的任务按照入队时间公平轮转。
实现上，我用了多个流来承载不同优先级。Redis Stream 本身支持按流消费，调度器分发任务的时候在两个 Stream 之间按权取任务，紧急流占 50% 的分配机会，默认流占 35%，后台流占 15%。比例是我根据实际负载调出来的，你可以按自己的场景调整。
5.2 失败重试与重试不击穿
任务失败了，先把失败原因分类：网络错误、解析错误、数据异常、被反爬拦截。不同类的失败策略不一样：网络错误重试三次，被拦截的重试次数更多但间隔指数退避，数据异常不重试直接标记失败并人工查看。
为了避免同一时间大量任务同时到期重试把目标站点冲垮，我在队列里给重试任务设置了延迟值，只有到达延迟时间的任务才会被重新消费。Redis Stream 的延迟投递不是原生功能，我是通过 ZSET 实现的：任务失败后写入 ZSET，指定触发时间，到期后由调度器扫描并重新投递。这个方案很老套但非常可靠。
5.3 节点伸缩：手动横向扩缩容就够用了
这个项目的规模下，我还不太需要自动伸缩。节点数量根据队列深度来调：如果待处理任务积压超过一个阈值，就在调度器页面上“扩容”按钮下，新的节点自动向调度器注册并领取任务；反之则手动下线一些空闲节点。
自动伸缩依赖指标采集和决策逻辑，复杂度会陡增，但收益在这个量级并不明显。如果以后要把节点数量规模翻几倍再考虑也不迟。保持简单，是分布式系统最重要的一条原则。
6. 会话复用与浏览器生命周期管理
无头浏览器的创建和销毁代价都不小，尤其是创建。频繁重建浏览器，不仅浪费 CPU 和内存，还会导致每次抓取都要重新加载缓存、建立新的 TLS 连接，目标站点很容易察觉异常。因此会话复用是整个集群提效的关键。
6.1 复用什么、不复用什么
浏览器实例内部是有多个标签页的。我的设计是：每个任务进入节点时，优先在当前浏览器实例里新建一个标签页完成抓取，抓完立即关闭这个标签页，但保留浏览器实例本身。这样做的目的是复用一个浏览器进程的系统资源，包括内存缓存、DNS 缓存、TLS 会话缓存等。这些我统称为“进程级缓存”。
不能复用的东西包括：页面级状态、登录态、Cookie。如果是需要登录的站点，绝不能让不同任务共享登录态，否则可能互相污染导致数据错乱。只能复用一个干净的匿名标签页，或者干脆为需要登录的任务单独启动一个专用浏览器实例。
6.2 标签页泄漏与浏览器实例回收
这个坑我踩得很深。如果代码里没有注意管理标签页生命周期，比如某个异常分支没有关闭标签页就返回了，时间一长，浏览器里的标签页数量会膨胀，内存持续走高，最终整个节点卡死。
解决方案是强制会话机制：每个任务无论成功或失败，在 finally 块里必须关闭该任务对应的标签页。另外，每个浏览器实例设定最大标签页数量，达到上限就整体重启浏览器。通过这一层兜底，标签页泄漏问题基本被根除了。
6.3 浏览器实例池的实现方式
节点上的浏览器实例数不是无限增长的。我维护了一个实例池，池大小等于 CPU 核数乘以一个系数（通常 2 到 3 之间）。比如一台 4 核的机器，实例池大小就是 8 到 12 个。每次有新任务进来，优先从池中取一个空闲实例使用；没有空闲实例就排队等待。实例空闲超过一定时间没有任务分配，就自动关闭以释放资源。
这套池化机制让节点能够稳定并发处理多个任务，同时避免了过多浏览器进程互相争抢资源而拖垮整机。
7. 抓取去重机制：布隆过滤器与增量采集
爬虫系统如果不去重，会有两个后果：一是存储空间白白浪费，二是给目标站点造成不必要的请求压力，还容易被封。在集群场景下，去重还需要考虑跨节点一致性，不能每个节点各记各的账。
7.1 哪些需要去重
去重的最小粒度是 URL。同一 URL 不应被重复抓取，这是最基本的。但很多场景下，还需要对内容本身做去重：比如一个列表页的标题虽然没变，但 URL 带了一堆追踪参数，直接按 URL 去重会认为这是两个不同的页面。这时候就需要基于内容特征做去重，比较常见的是对页面正文计算哈希，如果哈希相同则视为同一内容。
7.2 基于 Redis 的布隆过滤器实现
集群环境下的去重我用了布隆过滤器，而不是简单地把所有 URL 丢进一个 Set 里。原因是 Set 会随着数据量增长占用大量内存，而布隆过滤器的内存占用相对稳定，而且有极好的查询性能。
布隆过滤器存在误判概率，意思是可能会把“没见过的 URL”误判成“已经见过”，从而漏抓。这个概率可以通过参数控制，我在实现中将误判率控制在 1% 以下。对于大多数爬虫场景，1% 的漏抓概率是完全可以接受的，因为增量采集里本来就有周期性补扫逻辑，即使偶尔漏掉，下一轮也会补上。
实现上我用的是 Redisson 提供的布隆过滤器 API，直接在 Redis 里维护，不需要额外的存储组件。如果你的环境中没有现成的实现，可以自己用位图模拟，也不复杂。
7.3 指纹去重的具体实现
有的是对整页内容计算 MD5，有的是提取关键字段算哈希。我做的内容是结构化的数据，所以我的指纹是“站点 ID + 数据主体哈希”。这样同一个站点下，哪怕 URL 参数不同，只要主体内容一样，就判定为重复数据。
每次采集完数据后，先算指纹，然后去布隆过滤器里查一下是不是已有的指纹，是的话就丢弃这条数据，不是的话才入库并加入过滤器。这一步在节点上完成，避免了无效数据在集群内部的传输和存储。
8. 目标站点反爬应对策略的工程化方案
这部分内容比较敏感，也很容易写歪。先说清楚，我谈的反爬应对，全部是在遵守目标站点 robots 协议、尊重对方服务能力的前提下，做“合规且礼貌的采集”。重点不是教你绕过什么验证，而是如何在合理频率内稳定地完成数据采集，同时不给自己添麻烦。
8.1 请求频率控制是底线
任何反爬策略，最终都归到频率控制上。我在集群里对每个目标域名设置了全局并发上限，比如单域名最大 10 个并发任务。这个上限通过 Redis 的计数器实现：任务开始前获取信号量，任务结束后释放。
并发上限的数值怎么定？没有标准答案，主要看对方网站的响应速度和负载能力。我的经验是从小到大慢慢调：先设 5 个并发跑一天，观察响应情况，如果没有问题再慢慢往上加。加的过程中持续观察错误率和验证码出现频率，一旦有明显上升立刻回退。这个经验法我可以说是我做集群以来最有价值的一条，比任何花哨的伪装都管用。
8.2 浏览器指纹一致性
很多网站会在浏览器端采集特征，包括用户代理、语言、时区、屏幕分辨率、Canvas 指纹等。如果你每次请求都是不同的浏览器指纹，反而更像异常流量；如果指纹高度一致且可信，被特殊对待的概率反而低。
我的做法是给每个节点固定一个浏览器指纹配置，尽量模拟一台真实设备的完整特征：固定的 UA、固定的分辨率、固定的字体列表、固定的时区。这个配置在容器启动时通过参数注入，任务间保持不变。这样整个集群看起来就像一批稳定的用户设备在访问，而不是一群随机特征的无头浏览器在扫站。
8.3 验证码出现后的降级策略
验证码是绕不开的话题。我的策略很简单：不尝试自动识别，直接降级。出现验证码时，该任务暂停，标记为需要人工处理（通过一个简单的结果页面展示），同时系统自动降低该目标域名的并发并发上限。验证码自动识别本身也可以做，但涉及复杂的图像处理和模型推理，稳定性并不好，在这个场景里性价比不高。与其投入巨大精力在验证码对抗上，不如把频率控制做好，减少验证码出现的概率，这更根本。
9. 从零部署这套系统：实际操作步骤与指标监控
这一章我直接给出可复现的操作链路，以及系统上线后需要盯的指标。照着做你至少能部署出一个可用版本，再根据实际场景去调整参数。
9.1 环境准备清单
整个系统依赖的东西不多，大概有这些：
- 一台 Linux 服务器（或者几台，取决于你要跑的并发量）；
- Docker 和 Docker Compose；
- Redis（版本建议 6.0 以上）；
- 包含业务代码的 worker 镜像和基础浏览器镜像；
- 一个简单的任务发布脚本（通过命令行或页面接口往队列里推任务）。
如果你只有一台机器，也可以在一个节点上跑整个集群，唯一要注意的是资源分配要克制，比如限制 Redis 内存、限制浏览器实例总数。
9.2 集群搭建的每一步
第一步，先把基础浏览器镜像构建好。这一步要耐心，因为浏览器依赖的系统库比较多，镜像构建容易失败。建议直接用官方推荐的基础镜像，然后自己再追加字体和常用依赖。
第二步，启动 Redis。如果是生产环境，别忘了配置密码和持久化策略。Redis 一旦挂了，整个集群就停了，它是整个系统里最关键的依赖之一。
第三步，启动调度器服务。调度器本身不需要连接浏览器，它只是在队列和节点状态之间做协调。启动完成后，确认它能正常访问 Redis 并注册自己。
第四步，启动 worker 节点。节点启动时会自动向调度器注册并拉取任务。这一步是最容易出现代码问题的环节，建议先把日志级别调到 DEBUG，观察一下节点是否能正确创建浏览器实例、能否顺利消费第一条任务。
第五步，用任务发布脚本推进去几条测试任务，检查整条链路：任务入库、节点消费、浏览器打开页面、数据采集、结果回写、状态更新。一切正常后，再放开并发量。
9.3 需要盯的关键指标
- 队列深度：待处理任务数量。如果持续积压，说明集群处理速度跟不上。
- 节点在线数：确保注册节点全部心跳正常。
- 浏览器实例内存：每个实例的平均内存，过高说明会话泄漏或者页面过于复杂。
- 任务成功率：成功任务除以总任务数，这个指标直接反映采集质量。
- 平均任务耗时：单个任务从取出到完成的时间，耗时上升往往是被反爬拦截的前兆。
- 代理池健康度：可用代理数量和失败率，代理池一旦枯竭要及时补充。
这些指标全部可以从 Redis 的状态字段里读取，不需要额外搭监控系统。如果你需要更直观的图表，也可以接一个简单的看板工具，数据源保持不变。
9.4 上线后的定期维护事项
浏览器版本要定期更新，因为网站的兼容性和浏览器引擎的渲染行为会变。Redis 里的过期数据也要定期清理，避免无用任务状态占用内存。代理池列表要定期清洗，把失效代理及时标记删除。定时任务的调度表达式（如增量采集频率）要根据数据变化速度和目标站点承受能力定期复核。
这些维护事项不是一次性的，而是一个持续运营的过程。我在实践中会每周做一次巡检，十几分钟就能看完一遍所有关键指标，把异常苗头提前处理掉。
10. 我踩过的几个坑与对应的规避方法
最后这部分是我最想分享的，因为每个坑都花了我不少时间和心力才填平。说一下具体场景和最终的解决方式，希望能帮你避开。
10.1 容器内浏览器启动失败：沙箱与共享内存问题
第一个大坑是容器内浏览器启动直接报错退出。原因就是之前提到的沙箱权限和共享内存空间不足。如果你自己搭环境也碰到浏览器启动失败，优先检查这两项。
10.2 Redis 单点故障导致整个集群停摆
Redis 是整个系统的枢纽，单点部署一旦挂掉，任务全部滞留，节点全部失联。我的第一版就这么挂过一次。后来我给 Redis 加了持久化，同时配置了哨兵模式做自动故障转移。这一步不复杂但极其重要，尤其是跑生产环境时。
10.3 任务结果重复写入问题
由于网络超时可能导致节点任务执行成功但回执状态时失败，于是任务被重新投递，同一份数据被写了两遍。这个问题的根治办法不是在写入时加锁（太复杂），而是在数据入库时利用指纹做唯一约束。如果你的存储支持唯一索引，把指纹列设为唯一键就可以了。我的做法就是加了一个唯一索引，重复写入直接报错跳过，然后任务状态标记为成功即可。
10.4 扩容后出现节点负载不均
刚开始扩容时，我发现新加入的节点任务执行率明显低于老节点。原因是我在节点注册时给每个节点设置了最大并发数，但老节点的并发数已经跑满了，新节点却因为配置问题没有用满。排查下来是参数不一致导致的。后来我把节点参数统一收敛到调度器端配置，节点启动时从调度器拉取自身配置，这个问题就解决了。
10.5 代理切换过于频繁触发风控
一开始我为了追求高成功率，每次请求都用不同的代理 IP，结果反而触发了目标站点的风控——因为同一个账号或同一浏览器指纹频繁更换 IP，本身就很像被盗号。后来我调整为“一个实例绑定一个代理”的策略，问题立刻缓解。这里也验证了一个观点：反爬对抗中，一致性往往比多样性更重要。
11. 这套集群还能怎么扩展
前面讲的都是最小可用闭环，如果你后续要继续做更大的规模，有几个方向是可以自然延伸的。
11.1 从手动扩容到自动扩容
当节点数量超过两位数时，手动扩容就会变得低效。可以接入基于队列深度的自动伸缩：队列积压超过阈值就自动拉起新节点，队列空闲超过一段时间就自动回收闲置节点。可以考虑用 K8s 或其他容器编排平台来管理节点生命周期，这样自动扩容就非常自然了。
11.2 多地域代理调度
如果你的目标站点有地域限制，代理池就需要按地域分类。调度器在分发任务时，可以根据任务的目标地域要求，把任务分配到相应地域的节点上。这套逻辑我前期就预留了，在队列任务属性里加上地域标签即可。
11.3 采集结果的实时计算管道
目前数据是采集完入库就结束了，如果还想做实时统计分析，可以再接一层流处理管道，把采集结果实时推进分析系统，比如统计关键词出现频率、热点信息变化趋势等。这个扩展点在架构上没有任何阻碍，因为数据已经是以结构化方式写入的，后续接各种下游都方便。
11.4 从通用集群到专用爬虫平台
如果你有很多不同类型的采集需求，可以把这套系统做成一个平台：用户通过界面配置目标站点、采集字段、频率和优先级，系统自动生成采集任务并调度。这就要求业务逻辑进一步抽象，比当前的单体任务要复杂一些，但方向是顺的。我是觉得等真的有这类需求再说也不迟，不必一开始就过度设计。
12. 一句话总结我的整套实践心得
做 Browser Cluster 浏览器自动化集群爬虫系统，收获远超预期。技术层面我掌握了容器编排、消息队列模式、分布式状态管理、资源池化这些通用技能，更关键的是建立起一套“复杂系统如何保持稳定”的思维框架。
如果只让我给出一条建议，那就是：先小后大，先稳后快。不要一开始就上几十个节点追求高并发，先把单节点的稳定性、频率控制、去重机制都打磨清楚，再去横向扩展。稳定的单节点是可靠集群的基石。这套逻辑放之任何分布式系统都适用。
最后分享一个小经验：集群跑起来之后，最值得投资的不是加更多反爬黑科技，而是建立一套能让你快速感知异常的监控习惯。很多事故如果能提前十分钟发现，处理成本会小一个数量级。这也是我这套系统里，我认为最值得你参考的设计决策。
