站群程序定时任务配置：避开这几个坑，批量更新才不翻车

站群程序定时任务配置这件事，说大不大，说小也真不小。配得顺，几十上百个站点排着队更新，人在睡觉内容照常上线；配得糙，半夜任务卡死，第二天起来一看，后台日志红了一片。我做站群维护这几年，踩过的坑比写过的配置多，挑几个实用的点聊聊。

站群定时更新为什么不能全挤在同一分钟

刚接触站群那会儿，我习惯把更新时间设成整点，比如每天 09:00。后来站点一多，问题就来了：几十个任务同时触发，数据库连接数瞬间冲高，部分站点直接报超时。那段时间我甚至怀疑是主机商在限速，查了半天才发现是任务扎堆。

后来改成按站点编号错峰，把整点拆成 5 分钟一档，分散到 09:00 到 10:30 之间。改动不大，超时提示肉眼可见地少了。这里有个细节：如果站点之间有内容关联（比如同属一个行业聚合页），错峰顺序最好也排一下，避免下游站点先更新、上游还没动，抓取时内容对不上。

任务队列的并发设置，别照抄默认值

多数站群程序会带一个任务队列模块，默认并发数通常给得比较保守。我见过默认值 1 的，也见过默认值 10 的，差别很大。并发开多少，取决于你服务器扛不扛得住，跟程序本身关系不大。

• 数据库连接池上限要先看清楚，并发数超过它，任务会排队等连接而不是报错，表现就是「看起来在跑，其实全堵着」
• 单核 VPS 上，并发 3 到 5 比较稳；配置好一点的独立服务器，10 到 15 也跑得动，但别一次拉满
• 如果任务里带图片处理或远程抓取，并发要再降一档，这类操作最吃 IO

这点我没有做严格的压测数据，更多是凭观察和经验，各位按自己机器实际情况微调。

失败重试和超时时间，配置里最容易忽略的两行

定时任务失败太正常了。网络抖动、目标站临时不可达、数据库锁等待，随便哪个都能让一次更新半途而废。关键在于程序怎么处理失败。

超时时间建议按任务类型分开设：纯文本发布给 30 秒左右够用，带采集或图片下载的任务，给到 120 秒甚至 180 秒。给太短，任务反复被杀；给太长，一个卡死的任务会占着队列位置不放。重试次数我一般设 2 次，间隔 10 分钟，再多就是浪费资源——连续失败两次，大概率是配置或环境出了问题，该人工看一眼了。

有个小技巧：重试任务单独放一个低优先级队列，别跟正常任务抢并发名额。

日志和监测：任务跑没跑，得能一眼看出来

定时任务最怕的不是失败，是失败了没人知道。我的做法是每天看一次任务执行记录，重点看两列：实际执行时间和状态码。执行时间跟计划时间偏差超过 15 分钟，说明队列有积压；状态码里重复出现同一个错误，八成是某个站点的接口或权限出了问题。

如果站群程序自带邮件或 webhook 通知，把失败告警打开。没有的话，写个简单的脚本每天汇总一次失败记录发到手机上也行。别嫌麻烦，等发现某个站半个月没更新，损失就补不回来了。

配置改完先小范围试跑

调完定时任务参数，别急着全量放开。挑两三个不重要的站点，把任务时间设到十分钟后，盯着跑一轮，看看执行日志、内容有没有正常入库、前台页面是否刷新。确认没问题再推给全部站点。

站群程序的定时任务配置，说到底就是「别贪快、留余量、有告警」九个字。听着简单，真做到位，半夜被叫起来处理故障的次数能少一大半。