影刀RPA进阶：我开发了一套店群管理系统，彻底解决200+店铺并发卡死痛点

一、半夜三点，电脑蓝屏，老板心态炸了

阿鹏在深圳做跨境电商店群，主攻东南亚Shopee，手里有将近250个店铺。

去年大促期间，他半夜给我打语音，背景里是风扇狂转的声音。

“林哥，又蓝了！我开了25个窗口同时跑活动领券，刚开始还挺顺，不到四十分钟内存直接飙红，整台电脑卡住不动，然后蓝屏重启。我已经三晚上没睡好了，这活动就三天，再这么搞下去，券没领到，电脑先废了。”

他的痛点非常典型。250个店铺，每个都要参加限时活动，串行跑根本来不及，并行跑又直接崩。他试过用多线程硬开窗口，也试过把任务拆分到三台电脑上同时跑，但管理成本直线上升，而且还是有几台会随机崩。

“我32G内存，i9处理器，这配置还不够？到底问题出在哪儿？”

我告诉他：“不是配置不够，是你的调度逻辑太粗暴。你把250个店铺当成250个独立任务，但你没管它们怎么排队、怎么回收、怎么处理异常。这就像让250个人同时涌进银行，没有一个叫号系统，不踩踏才怪。”

那天晚上，我决定把Alien系统里的并发调度模块单独拿出来，给他做一个“银行叫号式”的任务引擎。这就是后来Alien店群自动化管理系统的核心模块之一，也是我今天要深度复盘的内容。

二、为什么传统脚本一到高并发就崩？

在动手重构之前，我仔细分析了阿鹏脚本的结构。他的做法和大多数店群老板如出一辙。

主线程读取店铺列表，然后循环调用多线程，每个线程启动一个浏览器，登录一个店铺，执行影刀流程，跑完关闭浏览器。

听上去很合理，问题却一大堆。

第一，没有资源上限控制。脚本里开了多少个线程，就会同时启动多少个浏览器。一个Chromium实例启动就要几百MB，加载完页面轻松破G。25个窗口同时开，光浏览器就吃掉将近30G内存，还没算系统本身的开销，32G内存瞬间见底，不蓝屏才怪。

第二，进程回收形同虚设。流程跑完后，主线程只是简单地关闭浏览器窗口，但很多情况下，渲染进程、GPU进程、扩展进程并没有跟着退出。它们变成僵尸进程，在后台默默吃内存，越积越多，直到系统崩溃。

第三，任务调度完全裸奔。没有排队机制，所有任务同时争抢资源。一个任务因为代理掉线卡住了，线程就一直挂着等，占用着内存不释放。其他任务被堵在后面，整个系统越来越慢，直到彻底卡死。

用一句话总结：没有调度和隔离的“高并发”，就是给电脑上刑。

三、我的解法：把250个店铺的执行变成“银行排队”

Alien系统的并发调度引擎，设计灵感很朴素——银行取号排队。

你去银行办业务，先取号，然后在等候区等。窗口就那么几个，叫到你了你去办，办完了窗口空出来，下一个补上。不管大厅里坐了多少人，同时办业务的永远只有那几个窗口。

在Alien里，每个“流程+店铺”的组合被封装成一个任务对象，丢进异步队列。系统维护一个固定大小的槽位池，比如20个槽位。任何时候，只有拿到槽位的任务才能启动浏览器执行流程。执行完毕，浏览器优雅关闭，槽位释放，下一个排队任务自动补上。

这样一来，不管你有250个店铺还是500个店铺，系统同时占用的资源永远限制在20个浏览器窗口以内。内存稳定，CPU平稳，跑一整夜都不会崩。

在Alien的“自动化编排流”面板里，我把这个能力包装成了一个极其简单的操作界面。

阿鹏只需要做三步：把“Shopee活动领券”流程卡拖到编排区，勾选全部250个店铺，设置最大并发窗口数为20，点击“开始执行”。然后关屏幕睡觉。

系统在后台自动排队、调度、执行、回收。第二天早上他打开运行监控面板，绿色一排成功，红色几个失败（基本都是代理波动），点一下“重试失败项”，五分钟收工。

四、调度器的心脏：槽位控制 + 超时强杀 + 看门狗

这套银行排队模型在代码层面怎么落地？

我用Python的asyncio构建了整个调度核心。asyncio.Semaphore做槽位控制，asyncio.Queue做任务队列，每个任务用asyncio.wait_for包一层超时控制。

但这还不够。真正让我踩过坑之后才加上的，是一个资源看门狗。

第一次上线压测时，我贪快把槽位设到30。前半小时一切正常，内存曲线平稳得像条直线。然后内存突然从8G开始跳涨，12G、15G、18G，不到五分钟整台电脑卡住不动。我查任务管理器，发现有几个浏览器的渲染进程并没有随主窗口关闭而退出。再查日志，发现是几个领券流程跑完后，Shopee后台弹了一个“邀请您参与用户体验调查”的弹窗，流程逻辑里没处理这个弹窗，浏览器就一直挂着等，进程退不出，成了吃内存的僵尸。我当晚给调度器加了一个看门狗协程，每10秒巡检一次所有正在执行的任务，只要发现某个任务已经标记为“已完成”，但它对应的浏览器进程树还活着，看门狗就直接调系统命令，把这个进程树从根上杀掉。之后再也没出现过内存泄漏。
下面这段代码，是Alien调度器的核心骨架，槽位控制、超时强杀、看门狗巡检，全在里面：

importasyncioclassAlienScheduler:""" Alien高并发调度引擎：槽位控制 + 超时强杀 + 看门狗清僵尸 """def__init__(self,max_slots:int=20,task_timeout:int=3600):self.semaphore=asyncio.Semaphore(max_slots)self.queue=asyncio.Queue()self.task_timeout=task_timeout self._active_tasks={}asyncdefsubmit(self,task):awaitself.queue.put(task)asyncdef_worker(self,worker_id:int):whileTrue:task=awaitself.queue.get()asyncwithself.semaphore:self._active_tasks[task.uid]=tasktry:# 超时控制：超过指定时长未完成，强制终止awaitasyncio.wait_for(task.execute(),timeout=self.task_timeout)exceptasyncio.TimeoutError:print(f"[超时]{task.name}超过{self.task_timeout}s，强制回收")task.kill()exceptExceptionase:print(f"[异常]{task.name}:{e}")task.kill()finally:self._active_tasks.pop(task.uid,None)self.queue.task_done()asyncdef_watchdog(self,interval:int=10):""" 看门狗协程：每 interval 秒巡检一次， 杀掉那些已完成但进程还活着的僵尸任务 """whileTrue:zombies=[]foruid,taskinself._active_tasks.items():iftask.is_finished()andtask.is_process_alive():zombies.append(uid)foruidinzombies:print(f"[看门狗] 发现僵尸进程:{self._active_tasks[uid].name}，强制清理")self._active_tasks[uid].kill()delself._active_tasks[uid]awaitasyncio.sleep(interval)asyncdefstart(self,worker_count:int=20):workers=[asyncio.create_task(self._worker(i))foriinrange(worker_count)]watchdog=asyncio.create_task(self._watchdog())awaitself.queue.join()watchdog.cancel()forwinworkers:w.cancel()``` 在这套调度器里，`task.kill()`不是简单发个终止信号，而是会递归查找这个任务启动的所有子进程，调用系统命令把它们全部终止，确保不留下任何一个在后台偷内存的幽灵。## 五、高并发的另一半：环境隔离你可能想问，调度这么稳，那环境串了怎么办？ 这就是Alien系统里调度引擎和环境隔离矩阵必须绑在一起的原因。每一个任务在执行之前，都会从环境管理中心拉取对应店铺的独立Profile。 这个Profile包含：独立的浏览器用户数据目录（Cookie、缓存物理隔离），独立的代理IP（带认证），独立的浏览器指纹（基于上百套真实设备模板，创建时对Canvas、WebGL、字体列表做随机微调），以及窗口标题强制注入店铺名和ID，防止手滑。 即使20个窗口并发跑，每一个都是完全独立的数字身份，平台看到的是20个来自不同设备、不同网络、不同指纹的独立用户。调度负责“不乱”，隔离负责“不串”，两者结合，才是真正能扛住几百个店铺的商业级系统。## 六、从“蓝屏日常”到“稳如磐石”的真实效果系统交付给阿鹏后的第一次大促，他晚上十点设置好编排流，250个Shopee店铺全部勾选“活动领券”，并发窗口设20个，总耗时四个半小时。 期间内存占用最高11G，CPU温度没超过60度，风扇声音安静得像没在跑。第二天早上他打开报告，成功237个，失败13个（全是代理掉线），一键重试后全部完成。 他给我发了一条消息：“林哥，昨晚我睡了第一个不用提心吊胆的觉。电脑自己在那跑，比我招的那几个运营靠谱一万倍。” 他后来算了一笔账：以前大促期间，250个店铺的活动领券，需要4个人三班倒盯着，两天才能跑完一轮。现在一个人下班前设置好，第二天早上看报告，全自动。一年下来光人力就省了将近二十万，这还不算电脑不用再因为蓝屏去修了。## 七、给想自己搞高并发调度的朋友三点建议**第一，并发不是越多越好。**固定槽位，排队执行，资源上限卡死，比无限制开窗口稳定十倍。银行叫号模型是店群自动化最合适的并发范式。**第二，进程回收必须做绝。**别相信任何“自动退出”，得有自己的看门狗。任务状态是“已完成”，不等于浏览器进程真退了。**第三，调度和隔离必须一起做。**没有隔离的并发，跑得越快封得越快。每个任务必须带着自己独立的浏览器环境去执行。## 八、写在最后Alien系统从环境隔离到并发调度，再到Nuitka黑盒打包交付，每个模块都是我在店群自动化的泥潭里，用最朴素的工程方法，一行代码一行代码抠出来的。 它没有花哨的AI，也没有融资背书，它就是一款实打实能帮店群老板解决并发卡死、环境串号、人力黑洞的生产力工具。 如果你也在被几百个店铺的批量执行折磨，电脑一开脚本就蓝屏，欢迎来找我聊聊。 我是林焱RPA，一个用调度器和看门狗硬刚店群并发痛点的独立开发者。 （全文完）