Redis Sorted-Set TTL GC Capacity Bomb¶
概念概覽
問題模式¶
核心知識¶
問題模式¶
全局事件使用 Redis Sorted Set 儲存，key 的 TTL 在每次寫入時被刷新（EXPIRE 延後），但 set 內的舊成員（過期事件）不會自動 GC——只有 key 本身過期才會整批刪除。
後果¶
- 長跑活動（weeks/months）的 sorted set 會無限累積成員
- TTL 持續刷新 = key 永不過期 = 舊成員永不 GC
- 記憶體隨活動時長線性增長，無上限
修正方向¶
1. 主動 GC：定期 ZREMRANGEBYSCORE 刪除 score（timestamp）過舊的成員
2. 改用 per-day / per-epoch key（自然輪轉，TTL 有效）
3. 限制 sorted set 最大成員數：ZREMRANGEBYRANK 保留最新 N 筆
識別信號¶
- Sorted set key 的
ZCARD隨時間持續增長 TTL顯示 key 不會過期（-1）或 TTL 不斷被 reset
經驗教訓¶
-
Redis key TTL 和 sorted set 成員的生命週期是獨立的，key 沒過期成員就不會 GC
-
全局事件 key 被持續 EXPIRE 更新時，要特別審查成員是否有主動清理機制
-
容量炸彈通常在短期測試看不出來，需要估算長跑情境下的增長率
常見陷阱¶
-
假設「key 有 TTL 所以記憶體安全」——當 TTL 被持續刷新時這個假設失效
-
只測試短期（幾天）活動而不估算 30 天+ 場景的記憶體用量
最佳實踐¶
-
為 sorted set 設計主動 GC 策略（ZREMRANGEBYSCORE by timestamp 或 ZREMRANGEBYRANK by count）
-
監控 ZCARD 趨勢，設定告警閾值
相關概念¶
- CCU Capacity Planning（壓測數據推算法）
- grpc-proto-pool-re----dangling---
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Reward Claims Architecture — 共享：
game-server/ 獨特：reward-system,schema-design - Architecture Audit Methodology — 共享：
capacity-planning/ 獨特：architecture-audit,delivery-management - PostgreSQL Write Capacity Planning — 共享：
capacity-planning/ 獨特：1m-ccu,database - Twirp Admin RPC Audit Architecture — 共享：
game-server/ 獨特：admin,audit - Activity Framework GameDataProvider Constructor Injection — 共享：
game-server/ 獨特：activity-framework,dependency-injection
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-31 | c903e4ed-15e4-4a39-b7b8-30b428e38075 | 識別全局事件 sorted-set key TTL 被持續刷新但舊成員不 GC 的長期容量炸彈模式 |