TL;DR
本文记录我为 DeepSeek Harness 开源项目贡献的一次异步化改造实践。核心问题是前端构建产物上传阻塞 CI，根因是同步调用 AWS S3。改用 Celery 异步任务后，CI 耗时从 45s 降至 8s，成功率提升至 100%。
1. 背景与动机
DeepSeek Harness 是一个面向大模型评测与推理的自动化框架，其 CI 流程需要将前端构建产物同步至 CDN。随着资源规模增长，同步上传逐渐成为整个流水线的瓶颈，直接影响开发迭代效率。
2. 问题现象与排查
在 Vite 项目中，打包后需将静态资源同步至 CDN。原方案在 Node.js 脚本中直接循环调用AWS SDK上传。当资源增至 5000 个文件时，CI 进程内存溢出，且单线程串行导致耗时线性增长。监控显示 CPU 占用率 95%，但网络带宽利用率仅 10%。
3. 异步化改造方案
将上传逻辑剥离，改为将文件清单发送至 Redis Stream，由 Celery Worker 批量拉取并多线程上传。前端仅需维护manifest.json，无需关心传输细节。
# worker.py celery_app.conf.broker_url = 'redis://localhost:6379/1' celery_app.conf.result_backend = 'redis://localhost:6379/0' @celery_app.task(bind=True, max_retries=3) def upload_batch(self, file_paths): with ThreadPoolExecutor(max_workers=10) as executor: futures = [executor.submit(s3_client.upload_file, f, 'cdn/bucket') for f in file_paths] return [f.result() for f in futures]4. 性能验证与对比
使用redis-cli XINFO STREAM监控消息积压。优化前：单批 100 文件耗时 3.2s，总耗时 45s。优化后：批量提交 5000 文件，CI 构建阶段仅生成清单耗时 1.2s，异步上传在后台 4s 完成。内存峰值从 1.2GB 降至 300MB。
5. 开源贡献中的协作与收获
在向 DeepSeek Harness 提交 PR 的过程中，我通过 issue 讨论明确了改造边界，并在 maintainer 的反馈下补充了 Redis Stream 的异常重试与监控指标。这次贡献让我更深入理解了异步任务队列在 CI 场景中的工程价值。
6. 下一步建议
立即将 CI 中的同步上传脚本替换为上述 Celery 任务调用，并配置 Redis Stream 持久化策略为AOF。
