 Sakurasan
|
b2e500ff51
|
feat: 金额 decimal 精确计费、failover 按失败类型封顶、渠道小时桶预聚合、分层守护测试
- 计费：19 个金额字段 float64→decimal.Decimal，DB 列保持 numeric(20,8) 零迁移；
API 金额仍为 JSON number（MarshalJSONWithoutQuotes），前端零改动
- failover：保留时间预算，新增 OT_PROXY_FAILOVER_CAPS_NET/SERVER/RATE/QUOTA
按失败类型封顶换渠道次数（429/配额类瞬时失败时间预算形同虚设）
- 预聚合：新增 usage_channel_hourlies（schema v10），记账事务内同步 upsert，
长窗口渠道统计走桶不再扫明细，spent_last_30d 改扫 usage_daily，v10 一次性回填幂等
- 守护：internal/arch_test.go 用 go/parser 强制分层依赖（fail-closed）
|
2026-11-09 00:41:48 +08:00 |
|
|
Sakurasan
|
f1181150aa
|
perf: 亲和表分片、记账按驱动并发、访问日志与原始体控量
继续上一轮性能改造的剩余项：
- 会话亲和表分 16 片（原来一个全局 mutex，每个请求都要走一遍），
键改为内联 FNV-1a 的 64 位摘要（原先是拼接字符串 + hex，每请求两次分配），
请求路径上零分配；新增键稳定性/无分配/分片并发测试。
- 记账落库按驱动自适应并发：Recorder 按用户分片到多个 worker（同一用户恒定
同片，流水顺序不变）。SQLite 只有一个写者，实测 4 worker 会互相抢锁把
p99 拖到 19–34ms，所以 SQLite 固定 1 个、PostgreSQL 用 4 个。
新增多分片落库与顺序测试（用显式 worker 数在 SQLite 上验证语义）。
- 访问日志：每请求一次 log.Printf 直写 stderr，高 QPS 下是系统调用热点；
改为 64 KiB 缓冲 + 每秒 flush（写/flush 互斥，-race 已验）。
- 原始体控量：LogRaw 落库的请求体截到 256 KiB、响应体截到 1 MiB 并标注原始
体积，避免单条日志几十 MB 拖慢 usage_logs 查询与备份。
- 渠道加权随机选路从 crypto/rand + big.Int 换成 math/rand/v2 的 IntN，
去掉每请求的系统调用与两次分配。
跳过的两项与原因：
- 「PG 下把 model 目录查询合并成一次 JOIN」：目录已缓存 10s，冷路径每模型
10 秒才走一次，合并收益接近 0。
- 「每流一个 heartbeat goroutine」：Go 的 ticker 成本很低，千级并发流仍在
可接受范围，改动收益不抵风险。
实测（16 并发、mock 上游、SQLite）：p50 679µs→558µs、p99 2.6ms→2.2ms、
RPS 18.7k→23.9k。验证：go vet、go test ./...、-race（proxy/channel/usage）全绿。
|
2026-10-30 14:25:10 +08:00 |
|
|
Sakurasan
|
8c12207478
|
perf: 目录缓存与流式正文快路径，请求热路径开销减半
按性能分析逐项落地，实测对比（16 并发、mock 上游零延迟、SQLite）：
- 每请求 SQL 10 → 2：模型/渠道目录（模型行、绑定、渠道行）进程内缓存 10s，
运行期状态（冷却、健康）仍每次实时判定；管理端写操作经中间件、
健康状态变化经回调立即失效。新增 TestProxyRequestSQLBudget 钉住预算。
- 端到端 p50 1.3–1.6ms → 0.66–0.70ms，RPS 3.5–8.9k → 16–18k。
- 流式正文累积：字符串 += 改 strings.Builder（原为 O(n²)），
逐行 JSON 提取改字节快路径，并加廉价的子串预过滤、拿到输出 usage 后停累积。
500 块：949µs/7.9MB 分配 → 83µs/136KB。
- 请求体定点改写：模型映射从整包 unmarshal/marshal 改为顶层字段替换
（100KB：585µs → 29µs），stream_options 注入同理；requestText 改为
只在「上游没报用量」时按需提取，亲和键改用原始体前缀。
- 渠道满载背压：新增 Acquire 有界排队（OT_PROXY_CHANNEL_ACQUIRE_WAIT，
默认 150ms）；排队仍满时返回 503 + Retry-After 而不是 502。
实测渠道上限 4、16 并发：无排队 81 次 503；排队 150ms 后 400/400 成功。
- 记账按批聚合：同批同用户一次扣款、流水批量插入、日表按 (user,model,日期)
聚合，替代每行 5 条语句；幂等仍靠 ref_id 唯一索引兜底。
- gorm 开启 PrepareStmt（SQL 解析此前占 CPU 15%）；tiktoken 编码器按模型复用。
- 管理端用量列表不再返回原始请求/响应体（可能几十 MB），
改为 has_raw 标记 + GET /admin/usage/:id 按需拉取，前端弹窗打开时取。
验证：go vet、go test ./...、go test -race（proxy/channel/usage/tokenizer）、
vue-tsc、eslint、vite build 全绿；本地起 mock 上游实测列表/详情接口与
管理页弹窗按需加载。
|
2026-10-30 14:14:21 +08:00 |
|
|
Sakurasan
|
a3197e2146
|
fix: 记账同一 trace 防重复扣款
流水 ref_id 有唯一索引，但扣款本身没有：重试/重复 flush 场景下
同一 trace 会被重复扣钱。billUser 扣款前先查 ref_id 是否已存在。
在远端记账重写基础上合并防重检查与测试。
|
2026-10-30 01:21:43 +08:00 |
|
|
Sakurasan
|
984a31cbc5
|
fix: 记账可靠性——关停排空队列、失败重试、扣费不再静默；余额改 SQL 原子递减
- Recorder.Close 改为停止接收+排空残留，channel 不再 close（杜绝 send-on-closed panic），Close 后的 Record 走同步落库
- flush 瞬时 DB 错误重试 3 次，不再整批丢弃；事务内扣费/流水/日聚合失败一律打日志，明细与扣费不再静默脱节
- 扣费与管理员调余额改 SQL 侧原子加减（SQLite 驱动不支持 FOR UPDATE，读-改-写并发会丢扣费）；调余额 ref_id 改纳秒不再撞唯一索引
- 最后一个启用的管理员不可被降级/禁用（管理面锁死后 reset-admin-password 救不回）
|
2026-10-29 02:56:31 +08:00 |
|