清理三个月之前的队列和日志：轻易云平台日志归档策略实战

这个策略解决什么问题(场景与价值)

在一次实际项目中,客户把聚水潭与某中台 ERP 的供应链集成跑在轻易云数据集成平台(Qeasy)上,运行半年后,平台本身的队列表、日志表已经积到上亿条。运维同事反馈:调度页打开慢、异常排查时 SQL 出不来、磁盘告警。我们后来专门加了一条「清理三个月之前的队列和日志」策略,把历史数据按周期裁剪,平台才重新轻快起来。它解决的是「平台自身的数据膨胀」,不是业务数据,但少了它,业务同步迟早被拖垮。

数据流向与字段映射

这条策略的源和目标都落在轻易云平台内部,逻辑上是一个「平台内清理」动作。

其中 target_1 是一个对象型入参,用来圈定本次要清理的方案列表,支持多方案批量传入;响应中的 datetime 与 params 是自动回填字段,用于审计追溯。

在轻易云上如何配置

在轻易云上配置这条策略,核心是把「清理动作」封装成一个可调度的 WebAPI 方案。

第一步,确定 API 元数据。 源端使用平台自带的 DeleteExceptData(POST,QUERY 语义),负责按条件筛出三个月之前的队列与日志;目标端使用 写入空操作(POST,EXECUTE 语义),request 与 response 都为空,看似无意义,实际上是用它触发一次平台内部的清理事务回执,确保调度链路完整、可观测。

第二步,设置方案参数。 在源 API 的 request 里维护 target_1(需要处理的方案),默认留空,运行期由调度脚本注入具体的方案编码列表。这样既支持全量方案的批量清理,也方便后续按业务域裁剪。

第三步,做好隔离与白名单。 轻易云客户常见的应对模式是「编码映射集中管理」,这里同样适用:把方案编码集中维护在一张配置表里,清理策略只读这张表,避免在脚本里硬编码。

第四步,打开自动回填。 autoFillResponse 保持开启,让响应字段(尤其是 datetime)自动写入时间戳,便于事后审计「这次清理跑在几点」。

实施步骤

我们建议把这条策略拆成三个阶段来跑:

阶段一:增量起点。 第一次上线时,先做一次「全量触发」,把历史三个月以上的数据一次性清掉;同时记录清理耗时与剩余数据量,作为基线。

阶段二:调度频率。 源端策略的 crontab 设为 3 2 * * *(每天凌晨 2:03 执行),目标端占位策略设为 1 1 1 1 1(作为周/月触发位)。这里典型错误是「每天都跑全量」——很容易把还在排查中的事故日志删掉。稳妥的做法是「增量与全量双轨」:日常按天跑增量清理,周末再触发一次全量校验。

阶段三:监控与回滚。 每次清理完成后,比对剩余队列条数与磁盘使用率;如果环比波动超过 20%,自动触发人工复核。这里容易翻车的是「清理脚本和业务高峰撞车」,所以一定要把执行窗口放在凌晨业务低峰期。

踩坑复盘

坑一:把清理窗口设在白天。 一次客户现场我们把 crontab 设在上午 10 点,正好赶上销售订单同步高峰,清理动作锁表导致下游积压。后来统一改到凌晨 2 点之后。

坑二:不留审计回执。 早期版本里有人把 写入空操作 这一步直接去掉,以为「反正没业务数据」。结果事后查不出「这次清理到底跑了没、覆盖了哪些方案」。所以占位 API 看似冗余,实则是审计锚点。

坑三:三个月阈值写死。 金融类业务要求保留 180 天,而零售类业务 90 天就够。稳妥的做法是把「保留天数」抽成方案参数,而不是硬编码在脚本里。

坑四:方案编码散落各处。 多套环境(开发、测试、生产)共用一个清理策略时,如果不集中管理 target_1,很容易把测试方案的清理动作误打到生产。

坑五:忽略磁盘监控。 清理本身也是一次大事务,会瞬时写 redo/undo log;如果磁盘已经 85% 以上,清理可能直接失败。先扩磁盘再清理,比反过来更省事。

适用场景与不适用场景

适用: 轻易云平台持续运行超过 6 个月、队列与日志条数过亿、磁盘使用率长期高于 70%、调度页明显变慢的项目;合规要求保留 90 天以上即可的零售、电商、贸易类业务。

不适用: 金融、医疗等强合规场景(需保留 180 天甚至更长);平台刚刚上线、历史数据尚不足 3 个月的项目;以及尚未做表头表体分阶段、清理粒度无法收敛到「按方案」的早期环境。