添加密钥轮询间隔配置以优化KV缓存利用率 #365
Description
问题描述
当前项目采用轮询（Round Robin）策略来选择 API 密钥，每次请求都会轮换到下一个密钥。这种策略虽然能很好地实现负载均衡，但会最大程度地浪费上游 LLM 厂商的 KV 缓存。
KV 缓存浪费的影响
- 缓存命中率降低：同一用户/会话的连续请求被分配到不同 API 密钥，上游无法利用 prompt cache
- 资源浪费：每次切换密钥都需要重新计算和缓存 KV 状态
- 成本增加：更高的计算成本、更慢的响应时间、更多的 token 消耗
解决方案
核心思路
添加一个可配置的密钥轮询间隔参数，让用户可以控制多少次请求后才轮换到下一个密钥。
具体实现
1. 配置参数
在 SystemSettings 中添加：
KeyRotationInterval int `json:"key_rotation_interval" default:"1" name:"config.key_rotation_interval" category:"config.category.key" desc:"config.key_rotation_interval_desc" validate:"required,min=1"`2. 密钥选择逻辑
修改 KeyProvider 的 SelectKey 方法，添加计数器逻辑：
- 维护每个 group 的请求计数器
- 当计数器 < 配置间隔时，继续使用当前密钥
- 达到间隔后重置计数器并轮换密钥
- 失败时立即轮换，不受间隔限制
3. 存储支持
计数器状态需要持久化到 Redis 或内存中，确保重启后状态一致。
方案比较
| 方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 轮询间隔（本方案） | 简单、可控、向后兼容 | 仍有一定缓存浪费 | 大多数对话场景 |
| 会话粘性 | 完美利用缓存 | 需要会话管理，复杂度高 | 长对话场景 |
| 一致性哈希 | 负载均衡 + 缓存友好 | 实现复杂，可能不均匀 | 复杂负载均衡 |
总结
对于本项目简单、高效、企业级的设计理念，轮询间隔方案是最合适的选择。