fix(multi-replica): 修复多副本部署下的状态互相破坏与重复执行

[Pengap]

背景

排查「这个项目能不能上 K8s、能不能 replicas>1」时发现：底子是按共享 PostgreSQL + Redis 设计的（迁移有 advisory lock、JWT 密钥落库收敛、扣费原子、约 25 个后台任务已有选主），但仍有六类问题会在多副本下真实出错。

在本地用 3–4 副本共享同一套 PG + Redis 的环境逐项复现并修复。修复前 2/14 项验收通过，修复后 14/14。

已 rebase 到最新 main。BackupService 的定时备份选主 main 上已有既有提交修复，本 PR 不重复，只保留 main 尚未覆盖的部分。

修了什么

1. 启动清扫会删掉存活同伴的在途并发槽 ⚠️ 最严重

ProvideConcurrencyService 在每个进程启动时无条件执行一次全局清扫，判据是「成员前缀 != 本进程随机前缀」。这个近似只在单实例下成立——同伴 Pod 的在途槽位前缀同样 != 本进程前缀，会被一并删除。每次扩容 / 滚动更新 / OOM 重启都会架空账号与用户的并发上限，造成超发准入。

「持有进程是否还活着」这个事实只有 Redis 看得到（唯一能观察到全部实例的地方），所以把它显式建模在那一层：

• 新增 concurrency:instances 存活实例注册表（ZSET，member = 进程前缀，score = 心跳时间）
• 清扫改为只删「不属于任何存活实例」的成员，前缀解析在 Lua 内完成
• 新增独立的 20s 心跳循环 —— 不能挂在 StartSlotCleanupWorker 上，那个间隔可配置甚至可设 0 关掉，心跳一断本进程的槽位就会被同伴回收
• 等待计数只在「本实例是唯一存活者」时才清零

代价：崩溃副本的槽位改为等心跳超时（90s）后回收，不再是重启即清。期间无人重启时由 acquire 路径的 ZREMRANGEBYSCORE 在一个 slot TTL 内兜底。

2. 两个周期性任务没有跨实例互斥

服务	多副本后果
ScheduledTestRunnerService	每个到期计划被 N 个副本各跑一次 → N 倍真实上游计费请求
ChannelMonitorRunner	N 倍探测上游、N 倍历史行

渠道监控按 monitor 维度加锁，不同监控仍可分散到不同副本并行，避免整体锁把探测串行化到单个副本。

3. 启动回收会删掉同伴正在跑的备份产物

recoverStaleRecords 把所有 running 记录判定为「我上次崩溃留下的」，会改写同伴正在进行的备份记录并删除其 S3 对象。

给 BackupRecord 增加 OwnerInstanceID，回收规则按可确定性分级：空 owner（历史记录）与本实例的记录立即回收；同伴的记录只有超过 2 小时才能断定已死，StartedAt 无法解析时不动。不对称是刻意的 —— 误判「还活着」只是记录多挂一会儿，误判「已死」是删数据。

4. 四家管理端 OAuth 的 PKCE 会话只在进程内存

Claude / OpenAI / Gemini / Antigravity 的 generate-auth-url 与 exchange-code 是两次独立 HTTP 请求，中间隔着用户在浏览器授权的数分钟，多副本下第二次会落到任意副本，成功率退化为 1/N。

抽出 redissession.Mirror 泛型（共享 Redis + 写失败降级本地），四个包接入。Grok 通道此前已用同款方案修复，这四家是漏的。

5. 冷启动引导竞态导致 CrashLoopBackOff

多副本空库同时启动时，AUTO_SETUP 的 CREATE DATABASE 与建管理员都是 check-then-act，输家撞唯一约束后经 log.Fatalf 直接退出。验收过程中真实撞到：

Auto setup failed: admin user creation failed:
pq: duplicate key value violates unique constraint "users_email_unique_active"

唯一约束本来就是这件事的仲裁者，之前只是把它的裁决误读成了错误：INSERT 改为 ON CONFLICT DO NOTHING 并按影响行数判定，CREATE DATABASE 容忍 42P04。

6. 进程内快照无跨实例失效 + 优雅退出不可配

• 渠道定价 / 模型映射 / 模型白名单与约 10 项系统设置，只在处理管理请求的那个副本立即生效，其余副本要等 TTL（10 分钟 / 60 秒）。对计费数据这是正确性问题：同一用户连续两个请求打到不同副本会被按不同单价扣费。新增 snapshot:invalidate:<topic> 广播（订阅端只做本地失效，绝不回广播，否则消息会在副本间无限回弹）。
• 优雅退出超时由硬编码 5 秒改为可配置（SERVER_SHUTDOWN_TIMEOUT，默认 30s），新增 SERVER_SHUTDOWN_DRAIN_DELAY 与 /readyz。收到 SIGTERM 后 /readyz 立即返回 503 供 K8s 摘除 endpoint，而 /health 保持 200 —— 它是 liveness 与 Dockerfile HEALTHCHECK 在用，关闭期翻转会被 kubelet 提前杀死，在途流反而截断得更早。

验收

本地 3–4 副本共享同一套 PG + Redis：

检查项	修复前	修复后
3 副本空库冷启动全部存活	概率性 CrashLoop	✅
存活同伴的在途并发槽	❌ 被清空	✅ 保留
已死进程残留回收	✅	✅
定时任务跨副本选主	❌ 无	✅ 4 个竞选者争同一把锁
实例心跳	❌ 无	✅ 100 次 / 95 秒
OAuth 会话跨副本可用	❌ session not found	✅ 副本2 带 code_verifier 调上游
快照失效广播订阅	❌ 无	✅ 4/4
关闭期 /readyz → 503	❌ 无端点	✅
合计	2/14	14/14

每一项都是先写失败测试复现、再修、再验证。新增回归测试覆盖：并发槽多实例语义（integration，真实 Redis）、实例心跳、任务选主、备份记录归属、四家 OAuth 会话跨实例、快照失效广播、就绪探针、引导幂等。

rebase 到最新 main 后重新验证：go build ./... + unit + no-tag + integration 全部通过。

兼容性

单实例部署行为不变 —— 未注入 Redis 时全部退化为原有的纯本地语义。

多副本部署要点

readinessProbe:  { httpGet: { path: /readyz, port: 8080 } }
livenessProbe:   { httpGet: { path: /health, port: 8080 } }
terminationGracePeriodSeconds: 60   # > SHUTDOWN_TIMEOUT + DRAIN_DELAY
env:
  - SERVER_SHUTDOWN_DRAIN_DELAY=8
  - SERVER_SHUTDOWN_TIMEOUT=30      # 跑长流式请求的部署调大
  - JWT_SECRET / TOTP_ENCRYPTION_KEY  # 必须显式注入
  - AUTO_SETUP=true 或 SKIP_SETUP=true
  - DATABASE_MAX_OPEN_CONNS × 副本数 不能超过 PG max_connections

本次未处理

进程内限流器（图片生成并发、防 API Key 爆破、Grok team 级限流）仍是每进程一份，实际全局上限 = 配置值 × 副本数。部署时把这几个值除以副本数即可，改成 Redis 计数器是个独立的重构。

backend-security / frontend-security 两个 CI job 的失败与本 PR 无关：前者是 govulncheck 报 go1.26.5 标准库漏洞（fixed in 1.26.6，涉及的调用点本 PR 一个都没碰），后者是 nanoid 的新公告缺少 audit 例外。两者都是 advisory 数据库随时间更新导致的既有问题。

[Pengap]

CI 结论：

• ✅ test / golangci-lint / frontend / shell 全部通过
• ❌ backend-security / frontend-security 失败，与本 PR 无关

已验证而非断言：把未经修改的 main 推到一个临时分支跑同一个 workflow，两个 job 同样失败 —— https://github.com/an-epiphany/sub2api/actions/runs/31789082437

原因是 advisory 数据库随时间更新：

• backend-security：govulncheck 报 go1.26.5 标准库漏洞（fixed in 1.26.6）。6 条 trace 涉及的调用点（wxpay.go、http_upstream.go、aliyun_captcha_verifier.go、batch_image_provider_vertex.go、openai_ws_client.go）本 PR 一个都没碰
• frontend-security：nanoid 新公告 GHSA-2v37-7h3g-55p8 缺少 audit 例外。本 PR 未改动任何 frontend/ 文件与 lockfile

修法是升 Go toolchain 到 1.26.6 / 补 audit 例外，属于独立的仓库维护，建议另开 PR。