specsfy-specialist-redis

Redis

适用场景

• 用于设计基于 Redis/Valkey 的缓存、会话、速率限制器、分布式锁、简单队列或流，或诊断缓存击穿、热点键、意外逐出或服务不可用。
• 也用于审查生产环境中的持久化配置（RDB/AOF）、Cluster/Sentinel 或内存策略。
• 不用于建模持久化源数据——Redis 是加速器或临时性结构；事实来源及其完整性应由 $specsfy-specialist-postgres（或相关数据库）负责。
• 与 $specsfy-specialist-observability 配合处理生产环境中的缓存指标和告警；如果应用的缓存/队列驱动是 Redis，则与 $specsfy-specialist-laravel/其他框架配合。

流程

1. 明确数据用途（缓存、会话、队列、锁、计数器）、事实来源、所需的一致性，以及 Redis 重启并清空后对该数据丢失的实际容忍度。
2. 估算基数、平均值大小、读写速率、所需 TTL 和访问模式（随机、顺序、集中于热点键）。
3. 选择数据结构和稳定的命名空间键方案（app:recurso:id），避免键过于动态而导致键基数激增。
4. 明确设计缓存击穿、失效策略、重试，以及 Redis 不可用时应用的行为（fail open 或 fail closed）。
5. 根据数据的用途配置内存上限、逐出策略和持久化（或不持久化）——缓存可容忍丢失，锁和业务计数器则不能。
6. 测试并发（同一键的两次同时写入）、操作过程中到期、Redis 不可用，以及恢复（重启/故障转移后的冷启动）。
7. 在宣布方案就绪前，测量命中率、延迟（p50/p99）、内存使用量、连接数和热点键。

模式

• 为每个缓存键设置明确的 TTL，并按键定义由谁负责使其失效（写入事件、较短 TTL 或两者兼用）。
• 避免在生产环境中执行会阻塞 Redis 单线程事件循环的命令——KEYS *、受控维护之外的 FLUSHALL/FLUSHDB、对大型集合执行不带 LIMIT 的 SORT；遍历时使用带游标的 SCAN。
• 当不变量要求“读取并写入”且不能出现竞态条件时，使用原生原子操作（INCR、SETNX、GETEX）或 Lua 脚本（EVAL/EVALSHA，由 Redis 原子执行）。
• 将分布式锁视为带超时且所有者可验证的租约：在 SET key token NX PX ttl 中生成唯一令牌；释放锁时，只能使用先确认 GET key == token 再执行 DEL 的脚本——绝不无条件执行 DEL。
• 对不兼容的工作负载，分离命名空间/逻辑数据库和逐出策略——易失缓存与不可逐出的数据（队列、锁）不应竞争同一套内存策略。
• 不要存储未内嵌 schema 版本的序列化对象（这会增加将来迁移格式的难度），也不要在没有必要时将秘密（密码、原始令牌）存入值中——Redis 不是秘密保险库。
• 将 Redis 用作队列前，先确认其投递语义：Pub/Sub 是尽力而为的投递（订阅者缺席时消息会丢失）；Streams 搭配 consumer group 可提供至少一次投递，但需要显式 ACK，也需要消费者端进行幂等重处理。

反模式

• TTL 不加抖动的缓存：许多键在同一时刻过期，会对数据库造成惊群效应——在 TTL 中加入随机变化，或使用锁／提前刷新，可以避免同时出现峰值。
• 超时后盲目重试非幂等命令——如果原始命令已处理但响应丢失，重试会重复产生效果；请使用幂等操作或去重令牌。
• 基数不受控的键（session:<uuid> 未设置 TTL，永远累积）——内存会无限增长，直到 Redis 开始驱逐数据或因 OOM 崩溃。
• 使用简单的 SETNX + DEL 实现分布式锁，且不设置 TTL——进程卡住或在执行 DEL 前退出，会导致锁无限期滞留。
• 将默认的 maxmemory-policy（noeviction）视为自动缓存——使用 noeviction 时，达到内存上限后，Redis 会开始拒绝写入，而不是驱逐数据；如果应用未处理此错误，就会崩溃。

验证

• 测试缓存未命中、命中、操作过程中到期、模拟缓存雪崩以及 Redis 不可用等情况——每种情况都应记录预期行为，而不是只写“应该能用”。
• 在能复现真实拓扑的环境中检查内存上限、驱逐策略、持久化和故障转移（Sentinel/Cluster），而不只是在单个开发实例中检查。
• 观察 INFO、慢日志（SLOWLOG GET）和客户端指标，且不要在日志中暴露敏感值。
• 对比应用在有缓存和无缓存时的行为，证明缓存没有在关键路径上引入过期或不一致的数据。
• 未测试两个并发进程争用同一个键之前，不要宣称锁“安全”；未测试重新投递后的重新处理之前，不要宣称队列“可靠”。

相关技能

• $specsfy-specialist-performance-engineering 用于衡量 Redis 是否缓解了瓶颈，并检查负载下的成本、延迟尾部和回归。
• 当 Redis 缓存的数据源于关系型数据库，且数据的真实来源和完整性由该数据库保证时，使用 $specsfy-specialist-postgres。
• $specsfy-specialist-observability 用于生产环境中的缓存指标、告警和仪表板。
• 当客户端是框架的缓存／队列／会话驱动程序时，使用 $specsfy-specialist-laravel。
• $specsfy-specialist-docker/$specsfy-specialist-docker-swarm 用于打包和运维 Redis/Sentinel/Cluster。

请阅读 references/standards.md，了解数据结构、持久化、集群、安全和缓存模式。