Bug: SessionTracker ZSet 成员无限增长导致 Redis 内存泄漏

[sususu98]

问题描述

SessionTracker 模块中的 provider:*:active_sessions 等 ZSet 会无限增长，导致 Redis 内存持续增加。在我的生产环境中，单个 provider 的 ZSet 累积了超过 12 万个过期成员，所有 ZSet 合计超过 21 万个过期成员。

环境信息

• CCH 版本：最新 dev 分支
• Redis 版本：7-alpine
• SESSION_TTL 配置：18000（5 小时）
• 运行时长：约 2 个月

问题根因

1. 写入与清理的不对称

写入操作（每次请求都执行）：

• trackSession() - 添加到 global、key、user ZSets
• updateProvider() - 添加到 provider ZSet
• refreshSession() - 更新所有 ZSet 的时间戳

清理操作（仅在读取时执行）：

• countFromZSet() - 调用 zremrangebyscore 清理过期成员
• 仅在 getProviderSessionCount()、getProviderSessionCountBatch() 等读取方法中触发

2. expire(3600) 无法生效

代码中设置了 expire(key, 3600)，但由于每次 zadd 都会刷新 TTL，只要有请求就永远不会过期：

// updateProvider() - 第 130-131 行
pipeline.zadd(`provider:${providerId}:active_sessions`, now, sessionId);
pipeline.expire(`provider:${providerId}:active_sessions`, 3600);

3. SESSION_TTL 硬编码问题

SessionTracker 硬编码了 5 分钟的 TTL，未读取环境变量：

// session-tracker.ts 第 20 行
private static readonly SESSION_TTL = 300000; // 5 分钟（毫秒）

// session-manager.ts 第 87 行 - 正确读取环境变量
private static readonly SESSION_TTL = parseInt(process.env.SESSION_TTL || "300", 10);

影响的 Redis Keys

Key 模式	清理触发条件	泄漏严重程度
global:active_sessions	Dashboard 查看	中
key:${keyId}:active_sessions	限流检查	低
user:${userId}:active_sessions	限流检查	低
provider:${providerId}:active_sessions	Dashboard 查看 / 限流检查	高

实际数据

provider:14:active_sessions: 120861 members, TTL=-1
provider:2:active_sessions: 44764 members, TTL=-1
provider:34:active_sessions: 13539 members, TTL=-1
provider:45:active_sessions: 11772 members, TTL=-1
provider:46:active_sessions: 7232 members, TTL=-1
...
Total stale members: 216,866

最早的成员时间戳距今 1777 小时（约 74 天），从未被清理。

建议修复方案

方案 1：写入时增加概率性清理（推荐）

在 trackSession()、updateProvider()、refreshSession() 中增加概率性清理，避免每次请求都执行清理：

// 在 pipeline 执行前，约 5% 概率触发清理
if (Math.random() < 0.05) {
  const expireTime = Date.now() - SessionTracker.SESSION_TTL;
  pipeline.zremrangebyscore(`provider:${providerId}:active_sessions`, "-inf", expireTime);
}

方案 2：统一 SESSION_TTL

从环境变量读取 TTL，保持一致性：

private static readonly SESSION_TTL = parseInt(process.env.SESSION_TTL || "300", 10) * 1000;

方案 3：后台定时清理任务

增加一个定时任务，定期扫描并清理所有 *:active_sessions ZSet。

临时缓解措施

# 手动清理过期成员（5 分钟前）
redis-cli ZREMRANGEBYSCORE "provider:14:active_sessions" -inf $(( $(date +%s%3N) - 300000 ))

# 或直接删除（会重建）
redis-cli DEL "provider:14:active_sessions"

相关代码位置

• src/lib/session-tracker.ts - 主要问题代码
• src/lib/session-manager.ts - SESSION_TTL 环境变量读取参考
• src/lib/rate-limit/service.ts - 限流检查触发清理
• src/actions/providers.ts - Dashboard 触发清理

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Related PRs

#554 - feat: 添加供应商查询缓存, 改善性能 [merged]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

感谢您详细的 bug 报告！

经过对代码的深入分析，我确认了您报告的问题确实存在，并且您的分析非常准确。以下是我的验证结果：

核心问题确认

1. 写入与清理的不对称（已验证）

写入操作（每次请求都执行）：

• trackSession() - src/lib/session-tracker.ts:66-108
• updateProvider() - src/lib/session-tracker.ts:118-153
• refreshSession() - src/lib/session-tracker.ts:165-218

清理操作（仅在读取时触发）：

• countFromZSet() - src/lib/session-tracker.ts:511-552
• getProviderSessionCountBatch() - src/lib/session-tracker.ts:358-458
• 其他 get*SessionCount() 方法

验证结果：清理操作确实只在调用以下方法时触发 zremrangebyscore：

• Line 384: getProviderSessionCountBatch() 中的批量清理
• Line 486: getActiveSessions() 中的清理
• Line 520: countFromZSet() 中的清理

2. expire(3600) 无法生效（已验证）

问题代码位置：

• src/lib/session-tracker.ts:76 - global:active_sessions
• src/lib/session-tracker.ts:80 - key:*:active_sessions
• src/lib/session-tracker.ts:84 - user:*:active_sessions
• src/lib/session-tracker.ts:131 - provider:*:active_sessions

每次 zadd 都会重置 TTL，导致 key 永远不会自动过期。正如您所说，只要有请求就永远不会过期。

3. SESSION_TTL 硬编码问题（已验证）

SessionTracker:

// src/lib/session-tracker.ts:20
private static readonly SESSION_TTL = 300000; // 5 分钟（毫秒）- 硬编码

SessionManager（正确实现）:

// src/lib/session-manager.ts:87
private static readonly SESSION_TTL = parseInt(process.env.SESSION_TTL || "300", 10); // 读取环境变量

环境变量配置：

• .env.example:62 定义了 SESSION_TTL=300（秒）

影响范围验证

您提到的 4 种 Redis Key 模式都存在此问题：

Key 模式	写入位置	清理触发位置	验证结果
global:active_sessions	trackSession:75, updateProvider:127, refreshSession:179	countFromZSet, getActiveSessions	✅ 确认泄漏
key:${keyId}:active_sessions	trackSession:79, refreshSession:180	countFromZSet via getKeySessionCount	✅ 确认泄漏
user:${userId}:active_sessions	trackSession:83, refreshSession:183	countFromZSet via getUserSessionCount	✅ 确认泄漏
provider:${providerId}:active_sessions	updateProvider:130, refreshSession:181	countFromZSet via getProviderSessionCount	✅ 确认泄漏（最严重）

相关代码位置（已验证）

所有提到的文件和行号都是准确的：

• ✅ src/lib/session-tracker.ts - 主要问题代码（20 行、130-131 行等）
• ✅ src/lib/session-manager.ts:87 - SESSION_TTL 正确读取环境变量的参考实现
• ✅ src/lib/rate-limit/service.ts - 使用 getKeySessionCount() 触发清理
• ✅ src/actions/providers.ts - Dashboard 调用 getProviderSessionCount() 触发清理

建议

您提出的三个修复方案都是合理的：

方案 1（概率性清理） - 在写入操作时增加 5% 概率清理，平衡性能和内存。这是最直接的解决方案。

方案 2（统一 SESSION_TTL） - 从环境变量读取 TTL：

private static readonly SESSION_TTL = parseInt(process.env.SESSION_TTL || "300", 10) * 1000;

这确保了配置一致性。

方案 3（后台定时清理） - 定期扫描并清理所有 *:active_sessions ZSet，最彻底但需要额外的后台任务。

建议优先实施方案 1 + 方案 2 的组合，既解决内存泄漏，又统一配置。

临时缓解措施

您提供的手动清理命令是正确的：

# 清理 5 分钟前的过期成员
redis-cli ZREMRANGEBYSCORE "provider:14:active_sessions" -inf $(( $(date +%s%3N) - 300000 ))

# 或直接删除（会在下次请求时重建）
redis-cli DEL "provider:14:active_sessions"

---

Automated response from Claude AI