Redis的使用场景

1. Redis 的定位：缓存 + 内存数据结构

Redis 的常见定位是两类：

• 缓存层：用内存降低数据库压力与延迟。
• 数据结构服务：提供计数、集合、队列、排名等能力，减少业务自建复杂结构的成本。

回答“使用场景”时，建议按数据结构来组织，更清晰也更贴近工程落地。

2. 按数据结构归类的典型场景

2.1 String：缓存、计数、分布式锁

• 热点缓存：Cache Aside（旁路缓存）最常见。
• 计数器：INCR / INCRBY。
• 分布式锁：SET key value NX EX ttl（需配合唯一 value 与 Lua 解锁）。

2.2 Hash：对象缓存与字段更新

把对象拆成字段（例如用户信息），适合做部分字段更新与读取。

2.3 List / Stream：队列与消息

• List：简单队列（LPUSH/RPOP）或阻塞队列（BLPOP）。
• Stream：更接近 MQ 的模型（消费组、确认、重放），适合轻量消息流。

2.4 Set：去重、集合运算

• 去重：用户 UV、已处理集合、幂等 key。
• 交并差：共同关注、共同好友等。

2.5 ZSet：排行榜、延迟队列

• 排行榜：score 做分数/时间戳，ZRANGE 取 TopN。
• 延迟队列：score 存触发时间，定时扫描 ZRANGEBYSCORE 取到期任务。

2.6 Bitmap / HyperLogLog / Geo：特殊统计

• Bitmap：签到、布尔标记、某天是否活跃。
• HyperLogLog：近似去重计数（省内存，允许误差）。
• Geo：地理位置附近的人/店（注意精度与热点问题）。

3. 缓存一致性：常见读写策略

3.1 Cache Aside（旁路缓存）

• 读：先读缓存，未命中再读 DB 并回填缓存。
• 写：先写 DB，再删除缓存（常见是“延迟双删”来降低并发脏读概率）。

一致性要求高时，需要结合业务容忍度选策略；Redis 本身不“保证与 DB 强一致”。

4. 工程实践：能跑稳比能跑快更重要

• Key 设计：前缀分层（业务:实体:主键），避免无界 key。
• 过期策略：合理 TTL，避免永不过期导致内存膨胀。
• 大 Key / 热 Key：控制单 key 体积与访问集中度，必要时拆分与预热。
• 持久化与高可用：需要数据可恢复时启用 RDB/AOF，并配合主从/哨兵/集群。
• 限流与降级：缓存/数据结构层也要有超时、失败降级，避免 Redis 故障放大。