轻易云实战教程:供应链集成中的「删除2个月前所有数据」策略配置

这个策略解决什么问题

某零售企业的供应链集成上线后,源系统与目标系统之间的中间数据(请求包、响应包、回执日志)会在轻易云数据库里逐月堆积。三个月后,单库突破数千万行,查询与归档备份明显变慢,后续同步策略的执行耗时也被拖长。

这时候需要一个「按方案维度清理 2 个月前所有数据」的兜底策略:它不参与业务字段搬运,只负责周期性瘦身,确保整个集成通道长期保持在一个健康的体量上。

数据流向与字段映射

这一策略没有传统意义上的源-目标业务字段映射,它的「源」是轻易云内部的策略执行记录表,「目标」是同一个表(执行后删除)。但从接口参数角度,仍然存在一条简洁的链路:

这里的关键点:target_1 是「需要删除哪些方案的历史数据」的入参,而不是业务字段。它决定了本策略作用于哪几个策略方案,这是配置时最容易被忽略的一环。

在轻易云上如何配置

进入轻易云数据集成平台后,在该策略的源端配置中,选择 WebAPI 写入方式,接口名填写 DeleteStrategyData,请求方法 POST,作用类型选 QUERY(查询/清理型),autoFillResponse 保持开启,这样 datetime 和 params 两个出参就会由平台自动回填,不需要在脚本里手动组装。

目标端配置一个「写入空操作」(WebAPI、POST、EXECUTE 作用),request 与 response 都留空。这个「空操作」看起来奇怪,实际上是轻易云策略编排里常见的承接动作——保证整条策略的上下游闭环、调度引擎能正确登记一次执行流水。

入参 target_1 的值,可以直接引用轻易云平台内部的方案常量或环境变量,把需要清理的那几个方案标识写进去。在我们接触过的客户里,稳妥的做法是把它放进「方案集中管理」的映射表里,而不是硬编码,后续要增减清理范围时,只改映射表就行,不用动策略本体。

实施步骤

第一步:确认清理范围。 在轻易云上打开「方案列表」,勾出所有需要被本策略清理的方案 ID。建议先把要清理的方案单独建一个分组,清理策略的 target_1 只引用这个分组,避免误伤别的方案。

第二步:配置源端 DeleteStrategyData。 按上文建好 WebAPI 元数据,target_1 用方案分组的引用值,请求体不需要额外业务字段。

第三步:配置目标端「写入空操作」。 这一步是兜底闭环,不能省。

第四步:设定调度时序。 源端 cron 建议放在 3 1 * * *(凌晨 1:03),目标端放在 23 2 * * *(凌晨 2:23)。两者错峰近一个半小时,确保源端删除完毕、平台落库后再触发下游空操作,避免在删除过程中并发写日志造成回滚。

第五步:首次全量与之后增量。 第一次上线时,可以手动触发一次,把积压的旧数据一次性清掉;之后每日按 cron 自动跑增量即可。在我们做过的项目里,「增量清理 + 首次全量兜底」是轻易云客户最常见的双轨模式。

第六步:观测与告警。 在轻易云的运行监控里盯两个指标:单次删除行数与执行耗时。如果某天删除行数突然归零,要排查是不是方案分组被改空了;如果耗时飙升,大概率是目标时间窗内并发清理任务撞车。

踩坑复盘

1. target_1 写错对象层级。典型错误是把方案标识写成纯字符串数组,平台识别后不会报错,但实际清理范围为空。稳妥的做法是严格按 object 数组传入,且每个对象里带上方案唯一标识字段。

2. 没有建方案分组,直接列 ID。后续每加一个策略都要改这个清理策略,改动面太大,极易漏改。建议用「方案分组 + 引用」的方式集中管理。

3. 源端与目标端 cron 撞在同一分钟。这会让平台在删除还没落库时,就把空操作写下去,导致运行流水缺失。错峰至少 30 分钟以上,我们一般拉到 1 小时以上更稳。

4. 首次上线忘了手动触发全量。结果前两个月旧数据按天一点点清,清理周期被拉得很长。上线当晚手动跑一次,后续就顺了。

5. 没关 autoFillResponse。会导致 datetime、params 两个出参拿不到,后续做日志审计或对账时缺数据。

适用场景与不适用场景

适用:中间数据长期堆积、需要按方案维度周期性瘦身的供应链集成场景;尤其是同步策略数量多、单策略日志增长快的项目。不适用:需要保留全量历史做合规审计的行业(如医药、食品追溯),以及源系统本身有归档机制、不依赖轻易云清理的项目。