chore: improve image worker logging

2026-07-09 11:57:06 +08:00
parent d79bd6fae9
commit 20a73440af
5 changed files with 70 additions and 2 deletions
@@ -281,6 +281,10 @@ python3.12 manage.py run_image_tasks \

 建议单独托管为 `cmhub-image-worker.service`。该 worker 从数据库 `image_generation_task` 表抢 `queued` 任务，使用 MySQL `select_for_update(skip_locked)` 标记 `running`，执行成功后写 `succeeded` 和稳定 `result_url`；失败或上游超时会调用计费层退点并写 `failed`。worker 循环会按 `IMAGE_TASK_REAPER_INTERVAL_SECONDS` 扫描租约或心跳过期的 `running` 任务，默认判失败并幂等退点，不默认重排队。

+worker 每处理一个任务会向 stdout 输出一行结构化日志，形如 `event=image_task_processed task_id=... status=failed alias=... duration_ms=... error_code=upstream_timeout`。失败日志必须用于区分「还在 queued 未提交给上游」和「已 running 但上游超时 / 失败」；日志不得包含 prompt、`image_base64`、provider raw 或密钥。
+
+多 worker 可以并行运行同一命令，只要 `--worker-id` 不同即可；MySQL 8.4 会通过 `select_for_update(skip_locked)` 避免重复抢同一任务。生产扩容应按 2、4、8、16 逐级观察 `queued` 长度、`duration_ms`、`error_code`、MySQL 连接数、VPS CPU/内存/磁盘写入和上游失败率。不要直接扩到 100 个 worker：这会同时放大 MySQL 连接、上游请求、图片下载和本地写文件压力；如果上游已经频繁 `upstream_timeout`，100 并发通常只会把失败更快放大。
+
 当前 worker 执行前会基于任务快照复跑一次生成准备逻辑，包括 prompt 复审、别名 / Provider 解析和定价检查；账务仍使用 submit 阶段已预扣的 `CallRecord.points_cost`，不会重复扣点。这是短队列下偏安全的取舍：敏感词库变更后，排队任务仍可在执行前被拦截并退款。若生产出现明显排队或频繁切换别名 / 模型，应单独开发“提交时模型配置快照”，让 worker 使用提交时确认的模型执行。

 输入方式对 submit 耗时有直接影响：桌面端批量生图应优先传 `image_base64`，submit 阶段只解码并写入输入文件；`image_url` 会在 submit 阶段完成 SSRF 校验、远程下载和大小限制，再保存为输入文件引用，因此可能阻塞提交请求。`image_url` 的好处是任务进入队列后自包含，worker 不再访问调用方外部 URL；生产排查 submit 慢时，应先确认是否有客户端批量使用 `image_url`。