Redis 常见应用场景有哪些？项目里该怎么选？

Redis 最常见的应用场景不是“把数据放进内存”这么简单，而是用它的低延迟、原子命令和多种数据结构，去补数据库、应用进程和消息系统的短板。项目里常见用法包括缓存、分布式锁、排行榜、计数器、限流、会话存储、轻量消息队列、地理位置和集合关系计算。真正要答好这个问题，重点不是背场景清单，而是说清楚每个场景为什么适合 Redis，以及什么时候不该用。

缓存是最高频场景

缓存通常用 Cache-Aside 模式：读请求先查 Redis，未命中再查数据库并写回缓存；写请求先更新数据库，再删除缓存。这个模式简单，但边界很多：不存在的数据要防缓存穿透，热点 key 过期要防击穿，大量 key 同时过期要防雪崩。实际项目里我会给 TTL 加随机抖动，并对空结果设置较短缓存时间。

java
User user = redis.get("user:" + id);
if (user == null) {
    user = db.queryById(id);
    redis.set("user:" + id, user, 3600 + random(300));
}
return user;

分布式锁和限流要看一致性要求

分布式锁常用 SET key value NX EX seconds，释放时用 Lua 比较 value 后再删除，避免删掉别人刚拿到的锁。它适合防重复提交、定时任务抢占、库存扣减前置保护，但不适合承诺绝对强一致；如果锁过期时间估短，业务没跑完锁就释放，会出现并发穿透。限流则常用 INCR、Sorted Set 滑动窗口或 Lua 令牌桶，固定窗口最简单，但窗口边界会有突刺。

排行榜、计数器和集合计算是数据结构优势

排行榜用 Sorted Set，ZADD 写分数，ZREVRANGE 查榜单，ZREVRANK 查名次，比数据库反复排序轻很多。阅读量、点赞数可以用 INCR 做原子计数，再异步落库。共同关注、标签筛选、用户分组适合用 Set 的交集和并集，但集合太大时要注意阻塞风险，线上不要随手对超大 key 做全量运算。

bash
ZADD article:rank 1024 article_1001
ZREVRANGE article:rank 0 9 WITHSCORES
SINTER user:1:follows user:2:follows

消息队列和会话存储要谨慎取舍

简单异步任务可以用 List 的 LPUSH + BRPOP，Redis Stream 支持消费组和确认机制，更像轻量队列。它的好处是接入快、延迟低；边界是消息堆积、重试治理和跨机房容灾能力不如 Kafka、RocketMQ 这类专业消息系统。Session 存 Redis 很常见，适合多实例共享登录态，但敏感字段要加密或只存引用 ID，不能把 Redis 当成无边界的安全仓库。还有一个常被忽略的点：Redis 不是持久化数据库的替代品，AOF 和 RDB 能降低丢数据概率，却不能让所有缓存场景天然具备事务语义。设计时要先问清楚“丢一小段数据能不能接受”，再决定是否把它放在 Redis 里，这个判断很关键。

追问

Redis 做缓存时，怎么处理缓存和数据库不一致？

常见做法是先更新数据库，再删除缓存，让下一次读取重新加载新值。这个方案牺牲了一点短时间一致性，换来实现简单和故障恢复容易。踩坑点是删除缓存失败会留下旧值，所以生产里通常配合消息重试、binlog 订阅或短 TTL 兜底。如果业务要求读到最新值，比如支付状态，就不要读缓存，直接读主库或走强一致链路。

Redis 做分布式锁可靠吗？

单 Redis 节点的锁只能解决大多数工程并发问题，不能等同于严格分布式共识。锁 value 必须是唯一 token，释放锁必须用 Lua 原子校验，否则会误删别人的锁。Redisson 的看门狗能降低锁过期风险，但如果进程 STW、网络抖动或 Redis 主从切换，仍要考虑幂等和补偿。重要结论是锁只能减少并发冲突，不能替代业务层一致性设计。

Redis Stream 能不能替代 Kafka？

低吞吐、少团队协作、希望快速落地的内部任务队列可以用 Redis Stream。它支持消费组、ACK 和消息 ID，比 Pub/Sub 可靠，但在超大吞吐、长期消息保留、多分区扩展和生态工具上不如 Kafka。项目里如果消息是核心链路，优先选专业 MQ；如果只是削峰、异步发通知或刷新缓存，Stream 够用而且维护成本低。

热点 key 和大 key 分别怎么处理？

热点 key 是访问太集中，可以用本地缓存、多副本读、key 分片或提前预热来分散压力。大 key 是单个 value 或集合过大，会导致网络传输慢、删除阻塞、主从同步卡顿，应该拆分存储并用 UNLINK 异步删除。两个问题经常混在一起，但处理方向不同：热点 key 关注流量，大 key 关注体积。上线前用 redis-cli --bigkeys 和慢日志排查，比故障后临时猜要靠谱。