KodouWZF 06852c5d90 perf(传输): 单轮处理上限从「10 个」改为「4 秒时间预算」 ...

个数不代表工作量：几十 KB 与几百 MB 的包差三个数量级，10 个小包 1 秒就跑完
（限制毫无必要），10 个大包能跑十几分钟（还会把下一轮挤掉）。改为时间预算后
单轮能处理多少就处理多少，超预算结束本轮、剩余留给下一轮，个数上限 500 兜底。
按 5.3 改造后的单包耗时估算，4 秒预算约可处理数十个小包，吞吐提升一个数量级。

同时解决三个会让预算被白耗的问题：
- 校验不通过原来只有一种处理（静默跳过、永不改名），但它有两重含义：光闸还在搬
  （下一轮就好）与包本身坏了（永远不会好）。用 mtime 是否静止超过 stale-after-seconds
  区分，坏包改名 .error 停止重试，否则 5 秒轮询会为它无限白跑
- 解包异常同样按静止阈值判定，短暂基础设施抖动仍保留重试
- .finish 文件名不合规原来只 log.warn 后保留文件，每轮重复解析并刷日志，改为标 .error

.finish 只做一次状态更新，改为优先处理且不受个数限制，让发送端尽早看到「已完成」。
每轮结束输出结构化日志（完成标记/成功/坏包/未就绪/耗时/预算/剩余/已搁置），
剩余超过 50 告警，作为容量规划依据。

按方案 5.3 注意事项补 max-unpack-size-mb（默认 512）：解包把整个 entry 读进堆，
upload 再拷一份、MD5 再一份，峰值约 2-3 倍文件大小，-Xmx3g 下单文件过大会 OOM，
超限直接标 .error 而不是尝试解包。

verifyFileMD5 打不开 zip 时原来记 ERROR 带堆栈，但「光闸还在搬」本来就是这个状态，
5 秒轮询下会为每个在途文件刷 60 条 ERROR，降为 debug；真正的坏包由改名 .error 时记 ERROR。

未实施方案里的认领改名与并发解包：两侧都是单实例部署，Spring 的 cron 任务要等上一轮
跑完才排下一轮（已实测触发间隔精确 5.00 秒），不存在同实例重叠；认领机制只会引入
kill -9 后遗留 .processing 这类新故障模式，换不到吞吐。若将来改多实例共享同一摆渡目录，
再补认领与 Redisson 互斥。

2026-11-03 22:42:06 +08:00

2.9 KiB

Raw Blame History

View Raw