目录
一、仓储测试数据问题
二、不好的清理方案
三、清理方案选择
四、整体清理方案
1、整体需求考虑：
2、整体清理过程
3、清理方案的关键实现点
4、风险控制
5、清理效果
未完结、出库、发运容器过多，直接阻塞后续正常实操(后续交接实操报timeout)
初步统计了一下量：4月~9月以来，未完结数据约7W左右
原因：自动化产生、测试数据使用不规范、系统异常、脏数据等
1、 干扰了日常的业务测试、自动化测试
2、 引发业务系统问题(类似自动化测试，引发线上问题，乃至故障，想必都听说过)
3、 直接对DB进行操作
上策：不影响日常联调、测试； 级联的业务脏数据一并清理了；不会给业务系统带来风险
中策：保证不影响日常联调、测试，允许级联的业务脏数据存在
下策：直接对DB操作
1、 满足业务限制： 只能查询30天内的数据；
2、每日有数据增量，需要定时清理；
3、大批量的存量数据，同时需要考虑安全清理；
4、有人工按需清理需求
1） 每个未完结容器，经历第一层清理。
2） 第一层清理无法清理掉的， 进入第二层清理
3）整个清理过程将异步完成
考虑了清理失败/异常时：
1）catch到系统异常(如报超时)，原地重试3次
2）catch到第一层清理异常，直接转入第二层清理
3）catch到第二层清理异常，直接转入sleep
4）转入下一个数据清理流程
由于整个清理过程时间较长(以数据量而定，可能小时级别)，采用 异步 + 消息通知方式清理执行时， 既配置了定时执行 ，又提供工具，可以手工执行
