直连加轮询,为什么越积越乱
先看这套做法怎么长出来,再看它坏在哪里、为什么补丁不够。

本课目标
读完这一课,你将能够
- 说出「直连加轮询」的做法,以及它的三个结构性问题
- 算出一个定时任务一个月跑多少次,判断它是不是在为「有没有变」付费
- 说出调慢、清理、加缓存这几种补丁为什么只治标
一个很自然的开始
智能体要用 ERP 里的数据,最省事的办法,是给它一个账号,让它直接连;想让数据「够新」,再加一个每隔几分钟跑一次的定时任务。第一个这样做的人没有错:它能用,也快。
问题出在第二十个、第五十个。每个看板、每个提醒、每个智能体都这样各接各的,谁也不知道别人接了什么。示例工厂就是这样长起来的:有人做了库存提醒,有人做了订单看板,有人做了每日回款汇总,每一个都带着自己的账号,设着自己的钟。
这些次数里,数据真正变过的有多少?多数时候,没有。轮询的成本只看次数,不看有没有变化。
三个「不唯一」
毛病不在某一条任务,而在三件事各有很多份:
入口
每个脚本、每个智能体都带着数据源的凭证直连。同一个数据源被反复查询,读得多、变得少;数据源越忙,越有人再加一个脚本去「盯」它。
触发
定时器、crontab、常驻的轮询循环,谁都能新建。没有准入,没有到期,失败了也不会自己停。
落脚点
结果整页上传到各自的报告站点,各有一套账号、一个数据库、一条发布流程。没有版本,换人就断。
三件事叠在一起,单点整改就会被另外两个抵消:清理了一批任务,新的很快又长出来;给站点加了缓存,脚本照样整页重传。
它是怎么坏的
这套做法坏起来很有规律。几乎每一处,都能对上下面四种情形之一:
- 失控增长:没有准入,也没有到期。任务只增不减,做完的项目留下的任务照样在跑。
- 静默失败:包装脚本吞掉了错误,任务状态只记「脚本跑完了」。数据源断了两天,页面照常显示,没有人被通知。
- 废弃的还在跑:改过名的、换过人的、被新版本取代的,旧任务没人对得上账,也没人敢停。
- 空转:不管有没有变化,每次都全量扫库、整页上传,或者调一次模型去「看看有什么新情况」。
拿示例工厂的库存提醒来对比一下:
| 直连加轮询 | 数据一变才触发 | |
|---|---|---|
| 什么时候查 | 每 5 分钟查一遍 | 库存变化时触发一次 |
| 没有变化时 | 照样查,照样花一次 | 什么都不发生,不花钱 |
| 同一物料反复低于安全值 | 每 5 分钟提醒一次 | 12 小时内只提醒一次 |
| 数据源断了 | 任务显示「正常」,页面停在昨天 | 发布端离线,页面能看见「数据可能不是最新」 |
补丁为什么不够
遇到这种局面,第一反应通常是补。每一种补丁都有效,但都只处理了三个「不唯一」中的一个:
| 能做到什么 | 为什么不够 | |
|---|---|---|
| 把 5 分钟改成 30 分钟 | 运行次数下降数倍 | 仍是轮询,变没变化与它无关 |
| 清理一批废弃任务 | 一次性干净 | 没有准入,过一阵又长回来 |
| 给报告页加缓存 | 回源流量下降 | 整页上传、多套账号、没有版本都还在 |
| 加监控告警 | 看得见了 | 只能发现,不能阻止新的随手建 |
| 写规范、做培训 | 少数人照做 | 智能体自己也会建定时任务,规范拦不住机器 |
要点
- 直连加轮询的毛病不在某一条任务,而在入口、触发、落脚点各有很多份。
- 轮询的成本只看次数:每 5 分钟一次,一个月就是 8,640 次,与数据变没变无关。
- 它坏得有规律:失控增长、静默失败、废弃的还在跑、空转。
- 调慢、清理、加缓存、加监控、写规范,各自只处理三个问题中的一个。
练一练
盘一盘你自己的系统
拿一个你熟悉的业务系统,不用改任何东西,只看。
列出所有直接连这个系统的脚本、智能体和应用,各写上用的账号和查询频率。
挑三个最频繁的定时任务,算出每月各跑多少次,再估计其中有几成看到的是没变的数据。
挑一个任务,问自己:如果它的数据源断了两天,谁会发现,靠什么发现?
小测
选一个答案,马上看解析。
Q1一个每 5 分钟跑一次的定时任务,一个月大约跑多少次?
一天 288 次,乘以 30 天是 8,640 次。288 是一天的次数,43,200 则是每分钟一次的月次数。
Q2库存提醒把「ERP 中断了两天」也记成了正常,最可能的原因是?
这是静默失败的典型:任务成功的定义是脚本退出,而不是数据取到了。
Q3为什么把 5 分钟改成 30 分钟不能根治问题?
次数少了,但每个脚本仍各连各的、各设各的钟。要改的是结构,不是频率。