 tamakyi
|
a2b7185a7b
|
头像链接落盘 + 并发获取 + 单块上限按命令行实测值收紧
一、头像链接的反查结果落盘（avatar_cache/uid_urls.jsonl，7 天有效期）
老录播的 jsonl 里没有头像链接，合并时要按 uid 向 AcFun 反查；但结果原来只存在内存里，
进程一重启就得把整场 uid 重新查一遍。实测一个 uid 约 1 秒，几百人的场次要几分钟，
日志还跟着打「正在获取头像：已处理 x/y 个用户」，看起来就像在重新下载头像
（实测图片缓存本身是好的：同进程第二轮、重启进程后第三轮都是「新增 0、重写 0」）。
现在查到就落盘（追加写，加载时顺手压掉重复/过期行），重启后直接读记录不再查。
有效期 7 天是为了主播换头像后能自己更新过来。
二、头像获取改成 6 路并发
查链接和下图都要走网络，串行做几百人要好几分钟。每个任务开头仍过闸门，
暂停/停止的响应不受影响（任务走带缓冲的 channel，worker 提前退出也不会卡住投递端）。
三、日志分清楚「复用」和「真下载」
原来的 looked++ 只看「这一条没有链接」，内存记忆命中时也会打印「已按 uid 向 AcFun 反查」，
误导成在重下。现在汇总成一句：链接复用 X / 向 AcFun 查 Y，图片复用缓存 Z / 新下载 W。
四、单块条数上限从 200 收紧到 120（线上事故）
线上一次 4 万条弹幕的合并在第 73 块失败：
"fork/exec ...: The filename or extension is too long"（就是 200 条上限那一版）。
真机实测：一块里每条弹幕来自不同用户时，每条占「-i 头像路径 + scale 行 + overlay 行」
约 241 字符 —— 120 条 28864 字符、200 条 48288 字符，而 Windows 的 CreateProcess 限 32767。
现在上限 120（给中文路径和其它参数留 3KB 余量），并加了一道自检：真超了就报
「ffmpeg 命令过长（N 字符）：这一块有 X 条弹幕、Y 个头像」，而不是烂在 exec 里。
顺带试过 -filter_complex_script（滤镜写文件、命令行只留文件名），
实测这个 ffmpeg 构建没有该选项（Unrecognized option），所以走收紧条数这条路。
验证：
- gofmt / go vet / go build / GOOS=linux go build 通过；go test 全绿（11.0s）；
go test -race 全绿（15.7s）；staticcheck -checks=all 零告警
- 新增 avatar_cache_test.go（11 个）与 command_len_test.go（3 个）用例；反向验证扩到 17 项全过
- 隔离实例：e2e.py 36 项、smoke_extra.py 33 项全过
- 新增 smoke_manyuid.py（300 条密集弹幕 / 300 个不同用户 / 全带头像，就是线上事故的复现场景）：
合并成功、分 3 块（120/120/60 条）、日志无「命令过长」；
第二次合并同一场「图片复用缓存 300 / 新下载 0」
|
2026-09-26 11:08:26 +08:00 |
|