 Blizzard
|
f16f63284f
|
feat(cluster): gateway 后台定时器加 leader 锁——多副本安全(B5)
此前两个 gateway 定时器(订阅推进/掉单补偿)每实例各扫一遍：多副本下重复查库，
且对微信查单调用量随副本线性放大(微信有频控，先被限流的是自己)。
store.TryRunExclusive：用 PG advisory try-lock 做集群级单实例执行(leader 选举)——每轮
tick 非阻塞抢锁，抢到才跑、跑完释放；抢不到说明别的实例是 leader、本轮跳过。自愈：锁随
持有连接释放，leader 挂了下一轮别的实例自然抢到接管，无需显式故障转移。订阅/补偿用不同
锁键(可由不同实例分别 lead)。非 PG(sqlite 测试)/无 DB → 退回本地直接跑(单实例安全)。
两个定时器的 tick 各包一层 TryRunExclusive。至此 gateway 可安全多副本(SSE 走共享 Redis
流无需粘性、状态全外置、JWT 无状态，剩数据层 HA 属 C 层 ops)。带 fallback 单测。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-21 16:21:31 +08:00 |
|
|
Blizzard
|
ac38d5e663
|
fix(prod): 后端生产级 A 类硬伤全清（7 项：授权/崩溃点/全表扫/限流/鉴权/限额）
部署前生产级审计（可靠性/数据层/安全三路）后，清掉 7 处代码级硬伤：
A1 后台定时器 goroutine 无 panic recover → 单个 DB panic 崩整个 gateway。加 safeGo/
safeCall，包住订阅/掉单补偿/微信推送/探针 goroutine，单轮 tick 再兜一层。
A2 提示词控制面(建/激活/停用，热广播全服务)只 RequireAuth → 任意登录用户改全局提示词。
三写端点+列表挂 RequireAdmin。
A3 HITL 审批端点无角色门 → viewer 可放行烧钱执行。加 RequireTenantRole(member)。
A4 审计/护栏列表 limit 无校验，limit=-1 让 gorm 取消 LIMIT 全表扫。加 clampLimit/
clampOffset，AdminTasks/AdminSpaces 补上界。
A5 限流 Redis 一挂就完全放行(fail-open)。加进程内固定窗口兜底(fail-safe) + 登录/注册
按 IP 专用严限流(10/min)。
A6 公开 by-id 端点(stream/exec/report导出/kb导入流)无鉴权无租户过滤。加
AuthFromHeaderOrQuery(从 ?token= 取 JWT) + task/report 按 owner 归属校验；桌面端
5 处 EventSource/下载 URL 经 tokenQuery 附 JWT。
A7 文件上传无大小上限(整文件进内存 OOM 面) → 50MB 闸(KB_MAX_UPLOAD_BYTES)+ LimitReader；
http.Server 加 ReadHeaderTimeout/ReadTimeout/MaxHeaderBytes(不设 WriteTimeout 保 SSE)。
带单测：clampLimit/safeCall/procLimiter/AuthFromHeaderOrQuery/TaskOwner。
build+vet+全量 test 绿；desktop tsc 绿。B(迁移工具/实时探针/出网韧性/登录锁定/leader选举)
与 C(TLS/PG HA/K8s/备份自动化/可观测)分期后做，参照 production_readiness.md。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-21 15:04:47 +08:00 |
|
|
Blizzard
|
80d4aaf4ba
|
feat(billing): 订阅制后端 —— 手动购买 + 周期发放积分 + 到期失效
规格（按需求）：用户扫码买一个订阅周期，有效期内每 N 天发一次积分，到期即失效，
不自动续费。N 与每次发放额度都在套餐里配，后台可改。
为什么不做自动续费：微信 Native 扫码支付没有代扣能力，真自动续费要走「委托代扣」
——另一套产品与资质。与其假装有，不如把"到期即失效"这个语义做扎实。
两个决定，都写进了代码注释：
- **发放语义是累加而非重置**。每次刷新写一条 grant 分录、余额累加。重置型
（月度配额清零）会让「余额 = SUM(ledger)」这条对账不变量变复杂，且有误清
用户自费积分的风险。
- **订阅开通放在 store.MarkOrderPaid 内**，而不是各调用方。回调与掉单补偿两条
路都经过它，放这一处才没人能漏掉；按 orderID 幂等，重复调用无害。
复用而非另造：订阅单与积分包单走同一条支付链路（下单/回调/查单/掉单补偿），
只是 kind=sub 且 credits_micro=0——积分不在付款时给，由订阅按周期发。
定时器每 10 分钟扫一轮，语义与幂等都在 store.TickSubscription 里，与手动触发
共用，不会两处漂移。停机期间欠下的发放会一次性补齐。
8 组测试。其中一条当场抓到真 bug：开通时原本无条件发一笔，同一订单重复开通
（回调重推/查单赛跑）会因序号自增绕过幂等索引，白送积分。改为开通也走与定时器
同一套排期判断——排期天然幂等。教训：幂等键要锚在业务时间轴上，不能靠自增序号。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-20 16:11:34 +08:00 |
|