Redis 常见用法：缓存、结构与过期策略

Redis 常被用作缓存、会话存储或轻量消息中间层。它很快，但不是数据库替代品。本文从缓存模式、数据结构、过期与运维几方面，整理在 Web 后端里使用 Redis 时的常见套路与风险。

为什么需要缓存

缓存解决的是读多写少、可容忍短暂不一致的场景：减轻数据库压力、削峰、降低延迟。若业务要求强一致、以数据库为准，则缓存只能是优化手段，不能改变一致性模型。

Cache-aside

读路径：先查缓存，未命中则读数据库并回填。写路径需明确是更新缓存还是失效缓存，避免长期脏读。批量预热与冷启动要有策略，避免瞬间压垮数据库。

击穿、穿透与雪崩

热点键过期瞬间，大量请求打到数据库叫击穿；可用互斥重建、逻辑过期或短期空值缓存缓解。穿透则是查询不存在的数据，可用布隆过滤器或缓存空结果。雪崩是大批键同时过期，需随机化 TTL 或分层过期。

限流与降级

在极端情况下，保护源站比返回完美数据更重要：令牌桶、滑动窗口可在网关或服务侧实现，Redis 也可参与分布式限流计数。

数据结构选型

• String：简单 KV、计数器。
• Hash：对象字段，适合会话或用户偏好。
• List：队列、最新 N 条（注意持久化需求）。
• Set：去重、集合运算。
• Sorted Set：排行榜、延时任务（按 score）。

内存与键设计

统一键前缀与命名规范，便于多服务共实例时隔离与批量扫描。避免单 key 过大（热 key + 大 value 会拖慢实例）。

持久化与高可用

RDB 与 AOF 各有取舍；纯缓存场景可接受丢失重建，关键数据则要副本与故障切换策略。云托管版本也要理解 SLA 与备份点。

与业务一致性

缓存失败时的降级路径（直接读库或返回友好错误）要提前设计，并在监控里区分「缓存 miss」与「缓存故障」。

运维与观测

关注内存上限、逐出策略、slowlog、大键与热点 key。定期 SCAN 审计异常模式，而不是在生产用 KEYS *。

小结

Redis 用得好，是性能放大器；用得随意，会变成不一致与故障的放大器。先定义缓存与数据库的职责边界，再谈结构与 TTL。