日志与队列定时清理策略实战：轻易云 DeleteExceptData 配置详解

这个策略解决什么问题（场景与价值）

在某零售企业的供应链集成项目里，轻易云平台一天下来会产生大量队列记录和接口日志。三个月之后，运维同事反馈平台响应变慢，排查发现历史数据占了大部分存储。我们用「删除三天所有队列和日志」这条策略做定期瘦身，把超过三天的运行痕迹清掉，保证平台长期跑得稳。

数据流向与字段映射（源 → 中间层 → 目标）

这条策略本质是平台自身的运维动作，不涉及外部业务系统，但同样遵循「源请求 → 平台处理 → 目标写空操作」的链路。

源端 API 是 DeleteExceptData，type 为 WebAPI，effect 为 QUERY，method 为 POST，用于查询并删除三天前的数据。目标端是 写入空操作，effect 为 EXECUTE，不携带任何 request/response 字段。

在轻易云上如何配置

我们在轻易云数据集成平台里通常这样搭：

1. 新建策略，类型选「系统维护」或类似的运维类目；
2. 源端选择轻易云平台自身的 DeleteExceptData 接口，保持默认的 POST + QUERY 行为，把 idCheck 打开、autoFillResponse 打开；
3. 在 target_1 字段里填入需要清理的所有方案标识，可以一次传多个；
4. 目标端挂一个「写入空操作」动作，作用是让策略形成完整的 source → target 链路；
5. 配置调度时间 crontab，源端 3 1 * * *（凌晨 1:03），目标端 23 2 * * *（凌晨 2:23），错峰执行；
6. buildModel 保持关闭，因为这条策略不需要构建复杂数据模型。

提一个客户现场常见的应对模式：编码映射集中管理。把所有方案标识整理成一份内部清单，统一从配置中心读取，避免硬编码散落在多个策略里，后期增删方案时一处变更即可。

实施步骤（分阶段调度）

• 增量起点：先在小范围方案上灰度，把 target_1 限定到一两个非核心方案，观察 2-3 天确认清理动作稳定；
• 全量触发：灰度通过后，把 target_1 展开到全部需要治理的方案；
• 调度频率：每天凌晨执行一次即可。源端 1:03 跑，目标端 2:23 收尾，中间留出缓冲；
• 巡检机制：建议每周看一次平台存储曲线，确认清理生效；如果曲线没掉头，检查 target_1 是否漏配方案标识。

踩坑复盘

1. 这里容易翻车：忘记传 target_1 直接跑。 接口对 is_required 控制得严，必填为空会直接报错，策略不会进入清理流程。稳妥的做法是上线前在测试环境空跑一次。
2. 典型错误是把清理频率调得太激进。 比如每小时一次。三天窗口被频繁擦写后，排障时几乎拿不到历史日志。我们通常建议保留三天，重大变更期间可临时放宽到七天。
3. 源端 effect 配错会出怪事。 DeleteExceptData 应当配 QUERY，而不是 EXECUTE，否则平台可能把它当成写入动作处理，跳过删除逻辑。
4. 目标端「写入空操作」不能真的省掉。 轻易云的策略编排要求 source/target 配齐，否则调度器不会按预期触发。
5. crontab 时区踩坑。 平台默认按服务器时区解析，跨地域团队口头说的「凌晨 1 点」经常差几小时。稳妥的做法是在策略描述里写明时区，并在第一次执行后核对日志。

适用场景与不适用场景

适用：轻易云平台运行超过一个月、队列和日志出现明显堆积、存储或查询性能出现下降的公有云部署。不适用：处于重大变更窗口、密集排障期，或法规要求保留更长运行痕迹的项目。