Redis实战模式

要解决的工程问题

Redis 在 AI Agent 系统中常作为缓存、限流、事件总线和原子状态中心，但工程实践中出现的「能用但难用」问题往往比性能瓶颈更致命。缓存键命名混乱导致键冲突与失效逻辑失效，无 TTL 的缓存随时间膨胀最终触发 OOM；使用 KEYS * 进行键扫描在生产环境阻塞服务线程，而 Pub/Sub 模式因无持久化导致消息丢失；Lua 脚本虽能保证原子性，但缺乏统一封装导致各 Agent 重复实现且维护困难。这些看似基础的使用问题，实则直接影响 Agent 系统的可靠性与可维护性。

技能如何组织能力

本技能将工程实践拆解为可落地的模式库与检查清单，覆盖四大核心能力：

1. 缓存策略：强制采用 entity:id:field 三级命名规范，所有缓存条目必须设置 TTL，防止内存无限增长。针对大对象（>100KB）需引入压缩策略，避免单键占用过高内存。
2. 限流与事件处理：通过 Sliding Window 与 Sorted Sets 实现高精度限流，避免固定窗口的临界点问题。事件处理采用 Streams 替代 Pub/Sub，通过消费者组、ACK 机制与回溯能力确保消息不丢失。
3. 原子性保障：封装 Lua Script 模板处理复合操作，如分布式锁需包含 Fencing Token 与 TTL 自动释放，避免死锁与竞态条件。
4. 资源管理：生产环境强制使用 SCAN 替代 KEYS 进行键匹配，连接池需配置 pool_size 与 idle_timeout 防止连接耗尽。

适用边界与注意点

适用于需要状态管理的 AI Agent 场景，但存在明确边界：

• 数据持久化边界：Redis 不适合作为主数据库，需与磁盘数据库配合使用，仅缓存热点数据与短期状态。
• 消息可靠性边界：Streams 虽支持持久化，但消息堆积时需结合 MAXLEN 策略防止内存溢出，且不适用于需要严格顺序保证的场景。
• 原子性边界：Lua Script 保证单节点原子性，但跨节点操作需结合分布式事务机制（如 Redlock）或业务补偿逻辑。