性能优化地图

本页面向修改代码的开发者，说明优化机会在哪些模块以及怎样避免把压力从一层转移到另一层。生产参数和扩容操作见容量与性能优化。

先拆延迟

总耗时
  = 入口/解析
  + API Key 鉴权
  + 权益与路由
  + 调度/排队
  + 上游连接与 TTFT
  + 流式传输
  + usage/日志收尾

使用已有 auth/routing/upstream/response latency、TTFT 和 Request ID 做基线。没有分段指标时，先补观测再优化。

热路径重点

API Key 鉴权

系统已有进程 L1、Redis L2、数据库回源、negative cache 和 singleflight。优化时重点看命中率、失效正确性和多实例一致性，不要简单延长 TTL 掩盖数据库压力。

调度

避免每个请求全量扫描数据库账号。关注 scheduler cache、outbox 更新、全量重建、粘性查询和并发状态往返。任何缓存都必须证明账号停用、限流和 Group 变更能及时生效。

协议转换

大 JSON、工具 schema、图片和流式事件会增加分配与复制。优化前用 profile 定位；不能用丢字段、合并事件或缓冲完整 SSE 换取表面吞吐。

Usage 与 Ops

请求完成后的写入、错误详情和聚合不能无限阻塞响应。异步化需要队列容量、丢弃策略、heartbeat 和恢复机制；“不阻塞”不等于允许静默丢账。

数据库

• 查询必须符合真实过滤和排序，避免大表 offset 扫描。
• usage/error 聚合优先预聚合和合适索引。
• 批量后台页面避免 N+1。
• 所有副本连接池总和受数据库上限约束。
• migration 评估锁表、回填和回退兼容。

Redis

关注 key 数量、TTL 抖动、热点、Lua/事务、连接池、网络往返和 eviction。Redis 故障时明确哪些功能 fail-open、fail-closed 或退化；鉴权、计费、并发和调度不能用同一策略概括。

优化验收

除了延迟/吞吐，还要回归：缓存失效、多实例、客户端取消、限流恢复、粘性切换、用量唯一性、费用、错误归因和内存。优化应能用基准、profile 或生产指标证明，而不是只凭代码更“简洁”。

当前系统不仅有性能优化空间，也有初始化恢复、健康检查、配置传播和支付补偿等可靠性演进项。它们的优先级高于无基线的局部微优化，见系统设计审视与演进建议。