我是林焱RPA一个跟浏览器进程和内存泄漏死磕了五年的独立开发者。半年前一个做店群的老哥凌晨三点给我打电话声音沙哑说他的服务器又崩了。一百多个店铺的自动化任务跑到一半界面卡死远程桌面都连不上只能硬重启当天的活动全泡汤。他说“我花了一万多买脚本结果三天两头崩我快被逼疯了。”这个场景我太熟了。市面上的店群脚本绝大部分都是单窗口循环或者用最粗暴的多线程根本不考虑并发控制和资源回收。短时间跑十几个号还行一旦上百个号同时铺开内存爆、CPU占满、浏览器进程残留接踵而来。老板们花了大价钱买设备却跑不稳天天半夜惊醒看电脑。我决定帮他重新做一套真正的并发调度系统。这就是Alien 店群自动化管理系统的并发引擎部分今天我会把它完整地拆开给你看——从窗口平铺、线程池调度到僵尸进程回收每一个细节都是真刀真枪踩出来的。一、店群脚本的并发之痛跑得起来和跑得稳是两码事店群自动化发展到今天很多工作室已经不再满足于“能跑就行”。一百个店只是入门两三百个店才是常态。每天要做的事包括签到、领券、做任务、上下架、回复每个店都要严格隔离环境每个操作都要按流程走完。这就对并发提出了极高要求。传统脚本的并发模式极其简陋要么是单线程顺序跑三百个店跑完已经第二天了要么是开一堆独立的脚本进程各跑各的但进程之间没有任何协调CPU和内存疯狂内卷店群矩阵自动化突破运营极限跑到一半系统崩溃 更糟糕的是 绝大多数脚本在窗口关闭后 浏览器进程还赖在后台 几分钟就能吃掉十几G内存 最后整个服务器卡死 只能强制重启。老板们花两万块买的服务器配置明明是64G内存加i9处理器结果还不如一台老旧的办公电脑稳定。问题就出在并发调度上——没有槽位控制没有资源回收没有健康检测。我当初接下这个需求的时候就在心里画了三条硬指标并发窗口数必须可配置且稳定在22个窗口以上无内存泄漏任何窗口关闭后其所占资源必须在1秒内回收干净系统需要能7×24小时无人值守运行这是一套商业RPA系统该有的底线。二、并发调度引擎的设计槽位、队列、回收三件套Alien系统的并发调度引擎我给它取名叫“智能平铺调度器”。它的核心逻辑非常简单temu店群自动化报活动案例一个任务队列一个固定大小的线程池 以及一个毫不妥协的进程回收器。2.1 槽位控制不给内存任何超载的机会很多开发者喜欢用ThreadPoolExecutor设一个最大值就完事但真正危险的是任务提交的阶段。如果一次性把所有任务都提交进去内部队列会无限膨胀大量的未完成任务持有浏览器对象内存直接上天。我的做法是只有当前运行的窗口数小于最大并发数时才从外部待执行队列里取一个新任务提交。这样同时在跑的浏览器窗口数量永远不会超过预设的22个或客户自定义的上限。我把这叫做“槽位式补充”就像停车场有空位才抬杆放车。2.2 任务队列与环境绑定的多对多分发在Alien的界面里老板会先在自己的环境管理中心准备好几百个独立的店铺环境再在自动化编排流里选择要执行的流程模板。点击开始后调度引擎并不是把流程和环境做一对一的绑定而是做多对多匹配同一个流程脚本被分发到不同的环境里同时执行。底层实现上我维护了一个全局的任务队列每个元素是 (环境对象, 流程定义) 的元组。 调度器从队列头部取任务 交给线程池中空闲的线程去执行。 执行完毕后 线程自动回到池中 调度器检测到有空槽 就立刻从队列里再取一个任务补上。 这样形成一个自循环的流水线 直到队列清空。2.3 资源强制回收杀进程不眨眼前面提到的那次经典崩溃正是让我下决心做强制回收的导火索。当时线上跑着30个拼多多上架任务十分钟内存从35%涨到96%鼠标都动不了。查日志发现每个上架流程结束时我确实关闭了浏览器窗口但用来自动化操作的WebDriver子进程还挂在系统里每个吃300多M内存30个就是9G再加上原本的浏览器占用内存直接爆炸。我一怒之下在任务结束的finally块里写了一个“环境进程灭绝”函数。它遍历系统所有进程检查命令行参数里有没有这个环境的唯一ID有就kill不管是不是僵尸一律清除。简单粗暴但极其有效。下面是这个调度器的核心骨架代码它把槽位控制、线程池和强制回收串在了一起。importpsutilfromconcurrent.futuresimportThreadPoolExecutor,wait,FIRST_COMPLETEDfromqueueimportQueueclassAlienConcurrentScheduler:Alien系统核心并发调度器槽位式补充强制进程回收def__init__(self,max_slots22):self.max_slotsmax_slots self.pending_tasksQueue()# 待执行任务队列defload_tasks(self,environments,flow_template):加载任务将环境列表与流程模板组合放入队列forenvinenvironments:self.pending_tasks.put((env,flow_template))defstart(self):启动调度循环withThreadPoolExecutor(max_workersself.max_slots)aspool:futuresset()# 持续执行直到队列空且所有任务完成whilenotself.pending_tasks.empty()orfutures:# 有空槽才补充任务whilelen(futures)self.max_slotsandnotself.pending_tasks.empty():env,flowself.pending_tasks.get()futurepool.submit(self._execute_with_cleanup,env,flow)futures.add(future)iffutures:# 等待至少一个任务完成释放槽位done,futureswait(futures,return_whenFIRST_COMPLETED)forfindone:# 实际工程会在此处理异常日志passdef_execute_with_cleanup(self,environment,flow):执行单个流程并在结束后强制清理环境的所有进程残留try:# Alien流程运行器根据环境配置启动隔离浏览器并执行步骤runnerAlienFlowRunner(environment)runner.execute(flow)finally:# 核心按环境ID消灭一切残留进程self._kill_env_processes(environment.env_id)def_kill_env_processes(self,env_id):根据环境唯一ID查找并杀死所有相关进程forprocinpsutil.process_iter([name,cmdline]):try:cmdproc.info.get(cmdline)ifcmdandany(env_idinstr(arg)forargincmd):proc.kill()except(psutil.NoSuchProcess,psutil.AccessDenied):continue 这套调度逻辑上线后 那个老板再也没在半夜接到过系统崩溃的电话。22个并发窗口跑满 内存能压在60%以下 任务排队执行 一个接一个 像流水线一样顺畅。 哪怕偶尔某个环境因为代理断了报错 它也会被回收干净 不会影响其他窗口。---## 三、界面上的一键并发让老板从“盯着屏幕”变成“看一眼就行”技术底层再稳 如果操作界面还是命令行 那老板们根本不敢用。 我在 Alien 的**自动化编排流**界面里 把并发控制的复杂性全部藏了起来 只留下两个老板最关心的元素**选流程、设并发数**。### 3.1 拖拽选环境勾选流程在Alien主窗口 左边是环境分组树 老板可以把“TK美区店铺”分组整个拖到执行区。 中间是流程模板库 每个模板都是从影刀RPA导出的标准流程 比如“TK活动全自动”、“多多批量上架”。 勾选一个流程 再勾选一批环境 然后在右上角设置一个并发数 比如22 点一下“开始执行” 后台调度器就开始工作。 老板不需要知道什么是线程池 什么是僵尸进程 他只需要看到实时日志窗口里 一排排绿色的“店铺A执行成功”滚过去就行。### 3.2 智能平铺的可视化监控我在执行面板里加了一个实时状态网格 每个小方块代表一个环境 当前在执行的就是旋转的绿色 等待中的是灰色 执行失败的是红色。 鼠标悬停在红色方块上 会直接显示出错原因。 老板一眼扫过去 就能知道现在跑得怎么样 不用再一个个翻日志。 这种把复杂的调度逻辑 变成直觉化的视觉反馈 是独立开发者最大的优势 你不用向任何产品经理妥协 可以直接把最符合用户心智的设计落地。---## 四、我用这套并发引擎跑过的真实业务场景单纯讲技术会显得干 我举两个真实落地的案例 来说明这套并发调度到底解决了什么问题。### 4.1 TikTok跨境店铺全自动活动一个做TikTok美区的客户 每天的核心工作 就是给两百多个店铺参加平台的各种活动 比如“创作者激励”、“直播任务”等。 以前他是让四个运营 每人分五十个号 用指纹浏览器手动点 从早忙到晚 还经常漏号。 用了Alien后 他把“TK活动全自动”流程导入 绑定所有美区环境 设并发数15 点击执行。 三个小时跑完两百多个号 一个都没漏 截图全自动归档。 四个运营直接裁掉两个 剩下的只用审核截图。### 4.2 拼多多批量上架商品另一个做拼多多百货店群的客户 每天要上架几百个商品 分布在八十多个店里。 传统做法是运营手动复制粘贴 三天才能上完一轮。 用Alien调度器 把“多多上架流程”绑定所有百货店铺环境 并发开到20 一个通宵就全上完了 第二天早上老板到公司 所有店的商品都已在售。 最关键的是 整个过程中内存稳如老狗 没有一次卡死。 老板后来跟我说 “我买你这个软件 最值的不是省了人力 是终于不焦虑了。”---## 五、并发调度之外Alien系统的其他工程考量这一篇重点聊并发 但一套能交付的商业软件 显然不止调度器。### 5.1 环境隔离是并发的前提如果环境隔离不彻底 并发跑起来 平台一眼就能看出十几窗口的指纹雷同。 我的做法是 在创建环境时 为每个店铺生成独立浏览器数据目录 并把指纹、代理、时区全部随机差异化。 这些我在之前的复盘里详细写过 这里不再展开 但必须强调**隔离是根调度是叶。**根不稳叶子越多死的越快。### 5.2 界面与交付让客户双击exe就用Alien系统使用 PyQt6 开发 打包成单个exe 内置所有依赖和浏览器内核 客户拿到手双击就能打开。 软件启动时会自动做机器码验证 不用客户折腾环境 这是商业软件的基本素养。 正因为做到了“稳”和“易用” 这套系统才真正在店群圈子里有了口碑。 很多老板是看了别人在用 主动找过来的。---## 六、对同行开发者的一点心里话写并发调度是个苦活 不像写个API那么风光 也不会出现在技术大会的PPT上。 但它实实在在地决定了 你的RPA系统是在给老板赚钱 还是在给老板添堵。 我经常在深夜调回收逻辑的时候想 我们这些搞自动化的 其实是在帮人抢回时间。 那些被切号、点鼠标、对账吞噬掉的时间 本可以用来陪家人 或者用来拓展更大的业务。 而一个稳定的并发引擎 就是这份自由的地基。 我是林焱RPA 还在不停优化这套调度器 下一步打算实现分布式多机协同 让上千个店铺也能丝滑运转。 如果你也在做RPA系统 或者正被并发卡死折磨 欢迎在评论区留下你的踩坑经历。 让代码替人熬夜 是我们这些人最大的浪漫。本文代码为脱敏后的调度核心逻辑完整的并发引擎设计及商业授权合作欢迎私信交流。稳定才是自动化最高的性价比。
RPA自动化实战：独立开发带并发调度引擎，终结店群百店卡死噩梦
发布时间：2026/6/4 16:30:17
我是林焱RPA一个跟浏览器进程和内存泄漏死磕了五年的独立开发者。半年前一个做店群的老哥凌晨三点给我打电话声音沙哑说他的服务器又崩了。一百多个店铺的自动化任务跑到一半界面卡死远程桌面都连不上只能硬重启当天的活动全泡汤。他说“我花了一万多买脚本结果三天两头崩我快被逼疯了。”这个场景我太熟了。市面上的店群脚本绝大部分都是单窗口循环或者用最粗暴的多线程根本不考虑并发控制和资源回收。短时间跑十几个号还行一旦上百个号同时铺开内存爆、CPU占满、浏览器进程残留接踵而来。老板们花了大价钱买设备却跑不稳天天半夜惊醒看电脑。我决定帮他重新做一套真正的并发调度系统。这就是Alien 店群自动化管理系统的并发引擎部分今天我会把它完整地拆开给你看——从窗口平铺、线程池调度到僵尸进程回收每一个细节都是真刀真枪踩出来的。一、店群脚本的并发之痛跑得起来和跑得稳是两码事店群自动化发展到今天很多工作室已经不再满足于“能跑就行”。一百个店只是入门两三百个店才是常态。每天要做的事包括签到、领券、做任务、上下架、回复每个店都要严格隔离环境每个操作都要按流程走完。这就对并发提出了极高要求。传统脚本的并发模式极其简陋要么是单线程顺序跑三百个店跑完已经第二天了要么是开一堆独立的脚本进程各跑各的但进程之间没有任何协调CPU和内存疯狂内卷店群矩阵自动化突破运营极限跑到一半系统崩溃 更糟糕的是 绝大多数脚本在窗口关闭后 浏览器进程还赖在后台 几分钟就能吃掉十几G内存 最后整个服务器卡死 只能强制重启。老板们花两万块买的服务器配置明明是64G内存加i9处理器结果还不如一台老旧的办公电脑稳定。问题就出在并发调度上——没有槽位控制没有资源回收没有健康检测。我当初接下这个需求的时候就在心里画了三条硬指标并发窗口数必须可配置且稳定在22个窗口以上无内存泄漏任何窗口关闭后其所占资源必须在1秒内回收干净系统需要能7×24小时无人值守运行这是一套商业RPA系统该有的底线。二、并发调度引擎的设计槽位、队列、回收三件套Alien系统的并发调度引擎我给它取名叫“智能平铺调度器”。它的核心逻辑非常简单temu店群自动化报活动案例一个任务队列一个固定大小的线程池 以及一个毫不妥协的进程回收器。2.1 槽位控制不给内存任何超载的机会很多开发者喜欢用ThreadPoolExecutor设一个最大值就完事但真正危险的是任务提交的阶段。如果一次性把所有任务都提交进去内部队列会无限膨胀大量的未完成任务持有浏览器对象内存直接上天。我的做法是只有当前运行的窗口数小于最大并发数时才从外部待执行队列里取一个新任务提交。这样同时在跑的浏览器窗口数量永远不会超过预设的22个或客户自定义的上限。我把这叫做“槽位式补充”就像停车场有空位才抬杆放车。2.2 任务队列与环境绑定的多对多分发在Alien的界面里老板会先在自己的环境管理中心准备好几百个独立的店铺环境再在自动化编排流里选择要执行的流程模板。点击开始后调度引擎并不是把流程和环境做一对一的绑定而是做多对多匹配同一个流程脚本被分发到不同的环境里同时执行。底层实现上我维护了一个全局的任务队列每个元素是 (环境对象, 流程定义) 的元组。 调度器从队列头部取任务 交给线程池中空闲的线程去执行。 执行完毕后 线程自动回到池中 调度器检测到有空槽 就立刻从队列里再取一个任务补上。 这样形成一个自循环的流水线 直到队列清空。2.3 资源强制回收杀进程不眨眼前面提到的那次经典崩溃正是让我下决心做强制回收的导火索。当时线上跑着30个拼多多上架任务十分钟内存从35%涨到96%鼠标都动不了。查日志发现每个上架流程结束时我确实关闭了浏览器窗口但用来自动化操作的WebDriver子进程还挂在系统里每个吃300多M内存30个就是9G再加上原本的浏览器占用内存直接爆炸。我一怒之下在任务结束的finally块里写了一个“环境进程灭绝”函数。它遍历系统所有进程检查命令行参数里有没有这个环境的唯一ID有就kill不管是不是僵尸一律清除。简单粗暴但极其有效。下面是这个调度器的核心骨架代码它把槽位控制、线程池和强制回收串在了一起。importpsutilfromconcurrent.futuresimportThreadPoolExecutor,wait,FIRST_COMPLETEDfromqueueimportQueueclassAlienConcurrentScheduler:Alien系统核心并发调度器槽位式补充强制进程回收def__init__(self,max_slots22):self.max_slotsmax_slots self.pending_tasksQueue()# 待执行任务队列defload_tasks(self,environments,flow_template):加载任务将环境列表与流程模板组合放入队列forenvinenvironments:self.pending_tasks.put((env,flow_template))defstart(self):启动调度循环withThreadPoolExecutor(max_workersself.max_slots)aspool:futuresset()# 持续执行直到队列空且所有任务完成whilenotself.pending_tasks.empty()orfutures:# 有空槽才补充任务whilelen(futures)self.max_slotsandnotself.pending_tasks.empty():env,flowself.pending_tasks.get()futurepool.submit(self._execute_with_cleanup,env,flow)futures.add(future)iffutures:# 等待至少一个任务完成释放槽位done,futureswait(futures,return_whenFIRST_COMPLETED)forfindone:# 实际工程会在此处理异常日志passdef_execute_with_cleanup(self,environment,flow):执行单个流程并在结束后强制清理环境的所有进程残留try:# Alien流程运行器根据环境配置启动隔离浏览器并执行步骤runnerAlienFlowRunner(environment)runner.execute(flow)finally:# 核心按环境ID消灭一切残留进程self._kill_env_processes(environment.env_id)def_kill_env_processes(self,env_id):根据环境唯一ID查找并杀死所有相关进程forprocinpsutil.process_iter([name,cmdline]):try:cmdproc.info.get(cmdline)ifcmdandany(env_idinstr(arg)forargincmd):proc.kill()except(psutil.NoSuchProcess,psutil.AccessDenied):continue 这套调度逻辑上线后 那个老板再也没在半夜接到过系统崩溃的电话。22个并发窗口跑满 内存能压在60%以下 任务排队执行 一个接一个 像流水线一样顺畅。 哪怕偶尔某个环境因为代理断了报错 它也会被回收干净 不会影响其他窗口。---## 三、界面上的一键并发让老板从“盯着屏幕”变成“看一眼就行”技术底层再稳 如果操作界面还是命令行 那老板们根本不敢用。 我在 Alien 的**自动化编排流**界面里 把并发控制的复杂性全部藏了起来 只留下两个老板最关心的元素**选流程、设并发数**。### 3.1 拖拽选环境勾选流程在Alien主窗口 左边是环境分组树 老板可以把“TK美区店铺”分组整个拖到执行区。 中间是流程模板库 每个模板都是从影刀RPA导出的标准流程 比如“TK活动全自动”、“多多批量上架”。 勾选一个流程 再勾选一批环境 然后在右上角设置一个并发数 比如22 点一下“开始执行” 后台调度器就开始工作。 老板不需要知道什么是线程池 什么是僵尸进程 他只需要看到实时日志窗口里 一排排绿色的“店铺A执行成功”滚过去就行。### 3.2 智能平铺的可视化监控我在执行面板里加了一个实时状态网格 每个小方块代表一个环境 当前在执行的就是旋转的绿色 等待中的是灰色 执行失败的是红色。 鼠标悬停在红色方块上 会直接显示出错原因。 老板一眼扫过去 就能知道现在跑得怎么样 不用再一个个翻日志。 这种把复杂的调度逻辑 变成直觉化的视觉反馈 是独立开发者最大的优势 你不用向任何产品经理妥协 可以直接把最符合用户心智的设计落地。---## 四、我用这套并发引擎跑过的真实业务场景单纯讲技术会显得干 我举两个真实落地的案例 来说明这套并发调度到底解决了什么问题。### 4.1 TikTok跨境店铺全自动活动一个做TikTok美区的客户 每天的核心工作 就是给两百多个店铺参加平台的各种活动 比如“创作者激励”、“直播任务”等。 以前他是让四个运营 每人分五十个号 用指纹浏览器手动点 从早忙到晚 还经常漏号。 用了Alien后 他把“TK活动全自动”流程导入 绑定所有美区环境 设并发数15 点击执行。 三个小时跑完两百多个号 一个都没漏 截图全自动归档。 四个运营直接裁掉两个 剩下的只用审核截图。### 4.2 拼多多批量上架商品另一个做拼多多百货店群的客户 每天要上架几百个商品 分布在八十多个店里。 传统做法是运营手动复制粘贴 三天才能上完一轮。 用Alien调度器 把“多多上架流程”绑定所有百货店铺环境 并发开到20 一个通宵就全上完了 第二天早上老板到公司 所有店的商品都已在售。 最关键的是 整个过程中内存稳如老狗 没有一次卡死。 老板后来跟我说 “我买你这个软件 最值的不是省了人力 是终于不焦虑了。”---## 五、并发调度之外Alien系统的其他工程考量这一篇重点聊并发 但一套能交付的商业软件 显然不止调度器。### 5.1 环境隔离是并发的前提如果环境隔离不彻底 并发跑起来 平台一眼就能看出十几窗口的指纹雷同。 我的做法是 在创建环境时 为每个店铺生成独立浏览器数据目录 并把指纹、代理、时区全部随机差异化。 这些我在之前的复盘里详细写过 这里不再展开 但必须强调**隔离是根调度是叶。**根不稳叶子越多死的越快。### 5.2 界面与交付让客户双击exe就用Alien系统使用 PyQt6 开发 打包成单个exe 内置所有依赖和浏览器内核 客户拿到手双击就能打开。 软件启动时会自动做机器码验证 不用客户折腾环境 这是商业软件的基本素养。 正因为做到了“稳”和“易用” 这套系统才真正在店群圈子里有了口碑。 很多老板是看了别人在用 主动找过来的。---## 六、对同行开发者的一点心里话写并发调度是个苦活 不像写个API那么风光 也不会出现在技术大会的PPT上。 但它实实在在地决定了 你的RPA系统是在给老板赚钱 还是在给老板添堵。 我经常在深夜调回收逻辑的时候想 我们这些搞自动化的 其实是在帮人抢回时间。 那些被切号、点鼠标、对账吞噬掉的时间 本可以用来陪家人 或者用来拓展更大的业务。 而一个稳定的并发引擎 就是这份自由的地基。 我是林焱RPA 还在不停优化这套调度器 下一步打算实现分布式多机协同 让上千个店铺也能丝滑运转。 如果你也在做RPA系统 或者正被并发卡死折磨 欢迎在评论区留下你的踩坑经历。 让代码替人熬夜 是我们这些人最大的浪漫。本文代码为脱敏后的调度核心逻辑完整的并发引擎设计及商业授权合作欢迎私信交流。稳定才是自动化最高的性价比。
