PPCWISER 琼仁智度 LogoPPCWISER琼仁智度
安全与可靠 · 定时任务

亚马逊广告定时任务：漏了会补，断了会续，卡了会救

广告自动化靠的是每天按时跑完的一串任务：同步数据、计算出价、下发、否词、提取。漏跑一次，出价就停在旧值；重跑一次，可能同一个调整被执行两遍。琼仁智度只认“做成了”，漏了会补、断了会续、卡了会救，而且不会重复执行。

免费试用 30 天看离线保护
30 天免费试用¥99/月/店铺起凭证只存你自己的电脑
你是否也遇到过

自动化最怕的，不是算错，而是没跑、跑两遍、卡住

漏跑一次，出价停在旧值一整天

服务重启、电脑卡顿，当晚的出价计算没跑成；第二天高峰时段，广告还在用前天的价格。

重启后同一任务跑了两遍

“按比例上调”被执行两次，出价被抬了两回；“新建”被执行两次，多出一批重复的广告。

任务卡住，没人知道

某个同步卡在半路，既不报错也不结束，后面的任务全在等它，直到有人发现数据一整天没更新。

不解决的代价

为什么“到点就跑”远远不够？

Google 的 SRE 实践把定时任务的失败分成两类：漏跑和重复执行。很多任务不是幂等的——同一个操作做两次，结果和做一次不一样，而且可能无法撤销；所以可靠的调度要分别记录任务“即将开始”和“已经完成”这两个时点，故障后才能判断该不该补、该从哪里续 [1]。

AWS 的可靠性实践指南也指出：“至多一次”或“至少一次”容易做到，“恰好一次”很难；修改类操作要做幂等设计 [2]；而重试如果没有退避与次数上限，就会在故障时叠加成重试风暴 [3]。

放到广告上，这些就是真金白银：漏跑是出价停在旧值，重跑是改价被执行两次，风暴是恢复瞬间被亚马逊限流、一半新价一半旧价 [4]。

系统怎么做

只认“做成了”：补、续、救，且不重复

  • 以成功记录为准。判断一个任务有没有执行，看的是这个窗口内有没有“成功完成”的记录，而不是“启动过没有”。
  • 漏跑自动补做。值班巡检定期检查，发现窗口内没做成的任务就补做；补做有次数上限和间隔，不会无限重试。
  • 中断自动接续。服务重启或被打断的任务，重启后自动接着做；出价计算开始前先记下“要算哪些”，进程中断后按原范围重新提交，直到算完。
  • 卡住有人收尾。长时间没有进展的任务由看门狗强制收尾，并留下诊断现场，不会一卡一整天。
  • 不重复执行。同一任务不会被两个入口同时执行；出价计算没结束之前不会开始下发；安装中转时会停掉旧版客户端的自动运行，避免新旧两套系统同时操作一个账户。
  • 数据库抖动自愈。数据库连接偶发中断时自动重连重试，不因一次抖动丢掉任务状态。
示意。补做的次数上限、间隔与超时阈值属于内部参数，不在页面公开。
你得到什么

每天该跑的，都跑完了；不该跑两遍的，只跑一遍

只认“做成了”

任务是否执行，以成功完成的记录为准，不会因为“启动过”就被当作完成。

漏跑自动补做

窗口内发现没做成的任务就补上，有次数上限与间隔。

断了自动接续

重启后接着做；出价计算中断会按原范围重新提交，直到算完。

卡住有人收尾

长时间没有进展的任务被强制收尾并留下诊断现场，便于定位原因。

不会跑两遍

同一任务单一入口；计算没结束不下发；新旧两套系统不会同时操作你的账户。

失败原因看得见

失败按原因归类展示；亚马逊明确拒绝的请求（例如对象已归档）不浪费配额反复重试，见 人工介入与失败统计。

对比

任务出了岔子，谁来兜底？

对比项手工运营通用 SaaS 工具（常见做法）PPCWISER 琼仁智度
判断任务是否执行— 凭记忆和表格— 视服务商✓ 只认成功完成的记录
漏跑之后✕ 发现了才补— 视服务商✓ 窗口内自动补做，有次数上限
中途被打断✕ 从头再来— 视服务商✓ 重启后自动接续
重复执行风险— 多人操作容易重复— 视服务商✓ 同一任务单一入口，计算完成前不下发
卡住的任务✕ 往往第二天才发现— 视服务商✓ 看门狗收尾并留下诊断现场

“视服务商”表示我们无法替其他产品作答，请以各服务商的说明为准。

用了以后

按时、按量、按顺序

出价不会停在旧值

当晚没跑成的计算与下发，会在窗口内补上，而不是等你第二天发现。

调整不会被执行两遍

以成功记录判断、单一入口执行，同一个调整只落地一次。

卡住不再拖垮整天

长时间没有进展的任务被收尾，后续任务照常进行，诊断现场留给排查。

你能看到它在值班

运营控制台的任务心跳与数据新鲜度，让“系统有没有在正常工作”一目了然。

与接入和广告结构的关系

每一个按结构设计的机制，都依赖任务按时跑完

出价、否词、精准提取、分层这些机制是按 广告结构 分工设计的，它们每天都要按顺序跑完一轮：先同步数据，再计算，再下发。任务可靠，是这些机制能正确生效的前提。接入后正式接管时，这些任务会自动注册并开始值班，见 上线接入流程。

关于定时任务的常见问题

补做会不会补出重复改价？
不会。系统以窗口内有没有成功记录来判断，只补做没做成的部分；已经成功的任务不会再执行。补做本身也有次数上限和间隔。
服务重启时，正在计算的出价怎么办？
计算开始前系统先记下这一轮要算的范围；进程中断后会按原范围重新提交，直到算完。计算没结束之前不会下发，所以不会把“算了一半”的结果推到亚马逊。
我能看到任务有没有按时跑吗？
能。运营控制台 展示任务心跳与数据新鲜度，哪个任务什么时候成功完成、数据更新到什么时候，一眼可见。
漏跑是因为我的中转电脑离线了，怎么办？
中转离线期间任务会推迟，回线后补做一次；离线超过 2 小时你和服务商都会收到提醒。详见 电脑关机、断网，广告不失控。
补做有没有时间限制？
有。补做只在各自的执行窗口内进行；错过窗口的，交给下一轮正常执行。

让每天该跑的任务都跑完，再开始试用

漏了会补、断了会续、卡了会救，而且不会重复执行。免费试用 30 天，先托管少量产品验证。

入门版 ¥99/月/店铺 · 含 10 个产品 · 每增加 1 个产品 +¥10/月
免费试用 30 天看价格与计算器
继续了解

相关功能

离线保护

关机断网不失控

离线推迟、回线补做一次、超 2 小时双向提醒，亚马逊上的设置照常生效。

查看 →可靠下发

限流下可靠下发

限流自动降速，三项成组安全下发，新建不重放，失败只补差。

查看 →数据完整

数据完整，宁缺不错

落库前校验、坏记录隔离、整轮熔断、原子替换、缺口回补。

查看 →运营控制台

运营控制台

经营驾驶舱 + ASIN 全景表 + 数据新鲜度 + 任务心跳，一屏看清全店真实经营。

查看 →透明与可控

人工随时介入

单条、勾选或一键推送新出价，防重复、自动重试、失败原因排行；还可按产品重算或暂停。

查看 →上线前必读

上线接入流程

7 个环节：准备 → 开通 → 装中转 → 录入 → 同步 → 选方案 → 接管，每步谁做、做完什么样都写清楚。

查看 →
REFERENCES

参考资料与权威来源

本页所有涉及亚马逊规则、行业数据与方法论的表述均标注来源。链接指向官方文档、同行评审论文、专利或法律法规原文；访问日期 2026-09。

  1. [1]论文Distributed Periodic Scheduling with Cron（Site Reliability Engineering 第 24 章） — Google SRE Book · 2016定时任务有“漏跑”和“重复执行”两类失败；许多任务不是幂等的，重复执行可能无法撤销，因此需要可靠记录任务“即将启动”和“已经完成”两个时点，才能在故障后正确恢复。
  2. [2]官方REL04-BP04 Make mutating operations idempotent — AWS Well-Architected Framework · Reliability Pillar · 2026分布式系统里“至多一次”或“至少一次”容易做到，“恰好一次”很难；修改类操作要做幂等设计并记录每个操作的状态，重试才不会产生重复记录或副作用。
  3. [3]官方REL05-BP03 Control and limit retry calls — AWS Well-Architected Framework · Reliability Pillar · 2026重试应采用指数退避加随机抖动并限制最大次数；过载引起的失败盲目重试只会更糟，多层叠加重试会形成重试风暴，对非幂等调用重试会产生重复结果。
  4. [4]官方Rate limiting — Amazon Ads API Docs · 2026请求过多时返回 429 并带 Retry-After 头，限流随系统负载动态调整，官方建议指数退避重试。