一、五百个店铺，一跑脚本就蓝屏，老板差点把电脑砸了
去年年底，一个做Shopee跨境的兄弟阿杰通过公众号找到我，上来就发了一段视频。
视频里，他的电脑屏幕上密密麻麻全是浏览器窗口，数了一下，大概有四十几个。然后画面突然卡住，鼠标不动了，紧接着蓝屏。
他发了一串语音：“林哥你看到没？我五百个Shopee店铺，光每天领个签到奖励就要搞死个人。想用影刀写个流程批量跑，一开二十个窗口就开始卡，开三十个直接蓝屏。我32G内存，i7处理器，这配置还不够？”
我问他具体怎么跑的。
他说，就是用Python写了个循环，读取店铺列表，然后多线程调影刀流程。一开始开了10个线程，勉强能跑，但是五百个店得跑七八个小时。他贪快，把线程数调到30，结果电脑直接罢工。 
“而且，”他补充，“跑着跑着，一些窗口明明流程结束了，浏览器却不关，像僵尸一样在后台吃内存。我得手动去任务管理器里一个一个杀进程。这么搞下去，别说自动化了，人都要疯了。”
我听完，感觉他的问题根本不是电脑配置的事。
是没有调度。
大多数店群老板对“并发”的理解就是“开更多窗口”，但并发的精髓是控制。没有控制的并发，就是一场内存泄漏的灾难。
店群矩阵自动化突破运营极限！
我对阿杰说：“你给我两周时间，我帮你把执行层从根上重构一遍。保证你以后跑五百个店，电脑稳得像块石头。”
这就是我后来在Alien系统里重点打磨的高并发调度引擎的故事。
二、店群并发的最大误区：多开窗口就是快
阿杰的问题非常典型，几乎每一个从“几十个店”扩张到“几百个店”的店群老板都会遇到。
他们的自动化思路往往很简单： 一个店铺跑一个流程，十个店铺就开十个窗口，一百个店铺就开一百个窗口。
速度确实上去了，但三分钟就崩。
核心矛盾在哪儿？
浏览器是内存大户。 一个Chromium实例，启动就要两三百兆，加载完页面轻松上G。 如果你一口气启动三十个浏览器窗口，30G内存瞬间吃光，系统开始疯狂换页，CPU上下文切换飙升，蓝屏只是时间问题。
进程管理是失控的。 脚本跑完一个店铺，有时候浏览器窗口关了，但渲染进程、GPU进程还挂在后台。 这些“僵尸进程”不断积压，内存越吃越多，直到系统崩溃。 阿杰手动杀进程的场景，我太熟悉了。
任务调度是裸奔的。 没有任何排队机制，线程之间互相抢资源，一个任务卡住了，后面全堵死。 更致命的是，代理IP可能复用，Cookie路径可能串，店铺环境互相污染。 
用一句话总结： 没有调度和隔离的“高并发”，就是给电脑上刑。
三、我的思路：把五百个店铺的执行变成“银行排队”
Alien系统的并发调度引擎，设计灵感其实很朴素——银行排队。
你去银行办业务，不是所有人一起涌到窗口，而是取号，然后在等候区坐着。 窗口就那几个，叫到你了，你去办，办完了，窗口空出来，下一个补上。
在Alien里，我把每个“店铺+任务”组合，封装成一个任务对象，丢进一个异步队列。
系统维护一个固定大小的槽位池，比如20个槽位。
任何时刻，只有拿到槽位的任务才能启动浏览器，去执行影刀的流程。 执行完毕，浏览器优雅关闭，槽位释放，下一个排队任务自动补上。
这样一来，不管你有500个店铺还是1000个店铺， 系统同时占用的资源，永远限制在20个浏览器窗口以内。 内存稳定，CPU平稳，跑一整夜都不会崩。 
我在Alien的“自动化编排流”面板里，把这个能力包装成了一个极其简单的操作。
temu店群自动化报活动案例
阿杰只需要：
系统在后台自动排队、叫号、执行、回收， 第二天早上他打开运行监控面板，绿色一排成功，红色几个失败（基本都是代理波动）， 点一下“重试失败项”，五分钟收工。
四、调度器的心脏：槽位控制 + 超时强杀 + 看门狗
这个银行排队模型，在代码层面是怎么落地的？
我用了Python的 asyncio 来构建整个调度核心。 asyncio.Semaphore 做槽位控制，asyncio.Queue 做任务队列， 每个任务包一层 asyncio.wait_for 做超时控制。 
但这还不够。
真正让我踩过坑之后才加上的，是一个资源看门狗。
当时第一次线上压测，我想试试极限，把槽位开到了25。
前半个小时跑得非常丝滑，内存曲线平稳。 然后突然，内存从8G开始往上涨，12G，15G，18G…… 我赶紧看任务管理器，发现有几个浏览器窗口明明已经跑完流程了， 但进程还挂在那里，每个占着三四百兆。 我查日志才找到根因：有两个店铺的签到流程，跑完后页面弹了个“评价本次服务”的弹窗， 流程逻辑里没处理这个弹窗，浏览器就一直等，进程退不出。 这些僵尸进程越积越多，内存就爆了。 那天晚上，我给调度器加了一个看门狗协程。
它每10秒巡检一次所有正在执行的任务， 如果发现某个任务已经标记为“已完成”，但它对应的浏览器进程树还活着， 看门狗会直接调用系统命令，把这个进程树从根上杀掉。
有了看门狗，再也没出现过内存泄漏。
下面这段代码，是Alien调度器的核心骨架， 槽位控制、超时强杀、看门狗巡检，全在里面了：
import asyncio
class AlienScheduler:
"""
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 = {} # 记录当前占用槽位的任务
async def submit(self, task):
await self.queue.put(task)
async def _worker(self, worker_id: int):
while True:
task = await self.queue.get()
async with self.semaphore:
self._active_tasks[task.uid] = task
try:
# 超时控制：任务超过指定时长未完成，强制终止
await asyncio.wait_for(task.execute(), timeout=self.task_timeout)
except asyncio.TimeoutError:
print(f"[超时] {task.name} 超过 {self.task_timeout}s，强制终止")
task.kill()
except Exception as e:
print(f"[异常] {task.name}: {e}")
task.kill()
finally:
self._active_tasks.pop(task.uid, None)
self.queue.task_done()
async def _watchdog(self, interval: int = 10):
"""
看门狗：每 interval 秒巡检一次，
杀掉那些已完成但进程还活着的僵尸任务
"""
while True:
zombies = []
for uid, task in self._active_tasks.items():
if task.is_finished() and task.is_process_alive():
zombies.append(uid)
for uid in zombies:
print(f"[看门狗] 发现僵尸进程: {self._active_tasks[uid].name}，强制清理")
self._active_tasks[uid].kill()
del self._active_tasks[uid]
await asyncio.sleep(interval)
async def start(self, worker_count: int = 20):
workers = [asyncio.create_task(self._worker(i)) for i in range(worker_count)]
watchdog = asyncio.create_task(self._watchdog())
await self.queue.join()
watchdog.cancel()
for w in workers:
w.cancel()
```
在这个调度器里，`task.kill()` 不是简单发个终止信号，
而是会递归查找这个任务启动的所有子进程，
调用系统命令把它们全部终止。
确保不留下任何一个在后台偷内存的幽灵。
## 五、高并发的另一半：隔离，不然跑得再快也是白跑
你可能会问：调度这么稳，那环境串了怎么办？
这是我在Alien里把**调度引擎**和**环境隔离矩阵**设计成一体的原因。
每一个任务在执行之前，都会从环境管理中心拉取对应店铺的独立Profile。
这个Profile包含：
* 独立的浏览器用户数据目录（物理路径不同，Cookie、缓存完全隔离）
* * 独立的代理IP（带认证，支持HTTP/SOCKS5）
* * 独立的浏览器指纹（基于上百套真实设备模板，创建时随机微调Canvas、WebGL、字体列表）
* * 窗口标题强制注入店铺名和ID（防止手滑）
即使20个窗口并发跑，
每一个窗口都是完全独立的数字身份，
平台看到的是20个来自不同设备、不同网络、不同指纹的独立用户。
调度负责“不乱”，隔离负责“不串”，
两者结合，才是真正能扛住几百个店铺的商业级系统。
## 六、阿杰的Shopee矩阵，从“蓝屏日常”到“稳如磐石”
系统交付给阿杰后，他当天晚上就跑了一次。
500个Shopee店铺，全部执行“自动签到领券”流程，
并发窗口设20个，总耗时4小时23分钟。
期间内存占用最高12G，CPU温度没超过65度，
一次蓝屏都没出现。
第二天早上他给我发了一条消息：
“林哥，我昨晚终于睡了一个踏实觉。电脑在那自己跑，风扇声音都小了。这要是放在以前，我得坐旁边盯着，随时准备按重启键。”
他后来还跟我说，他算了一笔账：
以前500个店铺的签到领券，如果让人工做，需要3个人干一整天。
现在一个人，下班前设置好任务，第二天早上看报告，全自动。
“这不是省了几个人的钱，是把我从焦虑里救出来了。”
## 七、给想自己搞高并发调度的兄弟三点建议
写了这么多，总结三个最核心的点：
**第一，并发不是越多越好。**
一个槽位一个坑，资源上限卡死，比无限制开窗口要稳定十倍。
银行排队模型，是店群自动化最好的并发范式。
**第二，进程回收必须做绝。**
不要相信任何“自动退出”，要有自己的看门狗。
任务完成 ≠ 进程退出，这是血的教训。
**第三，调度和隔离是绑在一起的。**
没有隔离的并发，跑得越快，封得越快。
一定要让每个任务带着自己独立的浏览器环境去执行。
## 八、结语
Alien这套系统，从环境隔离到并发调度，再到打包交付，
每个模块都是我林焱RPA在店群自动化的泥潭里摸爬滚打，
用最朴素的工程方法，一行一行代码抠出来的。
它没有什么花哨的AI，也没有什么融资加持，
它就是一款实打实能帮店群老板解决并发卡死、环境串号、人力黑洞的生产力工具。
如果你也在被几百个店铺的批量执行折磨，
电脑一开脚本就蓝屏，
欢迎来找我聊聊。
我是林焱RPA，
一个用调度器和看门狗，硬刚店群并发痛点的独立开发者。
（全文完）
