直连加轮询,为什么越积越乱

第 1 课 · 共 7 课 约 8 分钟

先看这套做法怎么长出来,再看它坏在哪里、为什么补丁不够。

本课目标

读完这一课,你将能够

  • 说出「直连加轮询」的做法,以及它的三个结构性问题
  • 算出一个定时任务一个月跑多少次,判断它是不是在为「有没有变」付费
  • 说出调慢、清理、加缓存这几种补丁为什么只治标

一个很自然的开始

智能体要用 ERP 里的数据,最省事的办法,是给它一个账号,让它直接连;想让数据「够新」,再加一个每隔几分钟跑一次的定时任务。第一个这样做的人没有错:它能用,也快。

问题出在第二十个、第五十个。每个看板、每个提醒、每个智能体都这样各接各的,谁也不知道别人接了什么。示例工厂就是这样长起来的:有人做了库存提醒,有人做了订单看板,有人做了每日回款汇总,每一个都带着自己的账号,设着自己的钟。

288每 5 分钟一次的任务,一天跑多少次
8,640同一个任务,一个月跑多少次

这些次数里,数据真正变过的有多少?多数时候,没有。轮询的成本只看次数,不看有没有变化。

三个「不唯一」

毛病不在某一条任务,而在三件事各有很多份:

ENTRY

入口

每个脚本、每个智能体都带着数据源的凭证直连。同一个数据源被反复查询,读得多、变得少;数据源越忙,越有人再加一个脚本去「盯」它。

TRIGGER

触发

定时器、crontab、常驻的轮询循环,谁都能新建。没有准入,没有到期,失败了也不会自己停。

HOME

落脚点

结果整页上传到各自的报告站点,各有一套账号、一个数据库、一条发布流程。没有版本,换人就断。

三件事叠在一起,单点整改就会被另外两个抵消:清理了一批任务,新的很快又长出来;给站点加了缓存,脚本照样整页重传。

它是怎么坏的

这套做法坏起来很有规律。几乎每一处,都能对上下面四种情形之一:

  • 失控增长:没有准入,也没有到期。任务只增不减,做完的项目留下的任务照样在跑。
  • 静默失败:包装脚本吞掉了错误,任务状态只记「脚本跑完了」。数据源断了两天,页面照常显示,没有人被通知。
  • 废弃的还在跑:改过名的、换过人的、被新版本取代的,旧任务没人对得上账,也没人敢停。
  • 空转:不管有没有变化,每次都全量扫库、整页上传,或者调一次模型去「看看有什么新情况」。

拿示例工厂的库存提醒来对比一下:

直连加轮询数据一变才触发
什么时候查每 5 分钟查一遍库存变化时触发一次
没有变化时照样查,照样花一次什么都不发生,不花钱
同一物料反复低于安全值每 5 分钟提醒一次12 小时内只提醒一次
数据源断了任务显示「正常」,页面停在昨天发布端离线,页面能看见「数据可能不是最新」

补丁为什么不够

遇到这种局面,第一反应通常是补。每一种补丁都有效,但都只处理了三个「不唯一」中的一个:

能做到什么为什么不够
把 5 分钟改成 30 分钟运行次数下降数倍仍是轮询,变没变化与它无关
清理一批废弃任务一次性干净没有准入,过一阵又长回来
给报告页加缓存回源流量下降整页上传、多套账号、没有版本都还在
加监控告警看得见了只能发现,不能阻止新的随手建
写规范、做培训少数人照做智能体自己也会建定时任务,规范拦不住机器

要点

  • 直连加轮询的毛病不在某一条任务,而在入口、触发、落脚点各有很多份。
  • 轮询的成本只看次数:每 5 分钟一次,一个月就是 8,640 次,与数据变没变无关。
  • 它坏得有规律:失控增长、静默失败、废弃的还在跑、空转。
  • 调慢、清理、加缓存、加监控、写规范,各自只处理三个问题中的一个。

练一练

盘一盘你自己的系统

拿一个你熟悉的业务系统,不用改任何东西,只看。

列出所有直接连这个系统的脚本、智能体和应用,各写上用的账号和查询频率。

小测

选一个答案,马上看解析。

Q1一个每 5 分钟跑一次的定时任务,一个月大约跑多少次?

Q2库存提醒把「ERP 中断了两天」也记成了正常,最可能的原因是?

Q3为什么把 5 分钟改成 30 分钟不能根治问题?

延伸阅读