前言

最近面试季，好多小伙伴都反馈同一个问题：“面试官问我Redis的使用场景，我只说了缓存，结果当场被怼——‘就这？’”

其实，Redis远不止“缓存”这么简单。

它是一个多才多艺的选手，凭借内存读写、丰富的数据结构、原子操作、持久化、高可用等特性，几乎渗透到了后端开发的所有角落。

今天这篇文章就专门跟大家一起聊聊Redis的11种使用场景，希望对你会有所帮助。

更多项目实战在Java突击队网：susan.net.cn/project

场景一：高速缓存（最经典）

业务场景

查询商品详情、用户信息等高频读数据，把数据库扛不住的读压力放到Redis。

代码示例（旁路缓存模式）

@Service
public class ProductService {
    @Autowired
    private RedisTemplate<String, Product> redisTemplate;
    @Autowired
    private ProductMapper productMapper;

    public Product getProduct(Long id) {
        String cacheKey = "product:" + id;
        // 1. 读缓存
        Product product = redisTemplate.opsForValue().get(cacheKey);
        if (product != null) {
            return product;
        }
        // 2. 缓存未命中，查DB
        product = productMapper.selectById(id);
        if (product != null) {
            // 3. 写缓存，随机过期时间防雪崩
            int expire = 300 + new Random().nextInt(60);
            redisTemplate.opsForValue().set(cacheKey, product, expire, TimeUnit.SECONDS);
        }
        return product;
    }
}

优点：性能从几十毫秒降到亚毫秒级，能扛极高并发。
缺点：存在短时间数据不一致（最终一致性）。
适用场景：商品详情、配置信息、用户会话等读多写少的数据。

场景二：分布式锁

业务场景

秒杀扣库存、订单防重、定时任务防重复执行——多进程争抢同一资源时，需要一把全局锁。

推荐方案：Redisson（自动续期、可重入）

@Service
public class SeckillService {
    @Autowired
    private RedissonClient redissonClient;

    public void doSeckill(Long userId, Long productId) {
        String lockKey = "lock:seckill:" + productId;
        RLock lock = redissonClient.getLock(lockKey);
        try {
            // 尝试加锁，最多等待3秒，锁默认30秒（看门狗自动续期）
            if (lock.tryLock(3, TimeUnit.SECONDS)) {
                // 扣库存逻辑...
                int stock = getStock(productId);
                if (stock > 0) {
                    updateStock(productId, stock - 1);
                } else {
                    throw new RuntimeException("已售罄");
                }
            } else {
                throw new RuntimeException("系统繁忙，请稍后再试");
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            if (lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

⚠️ 新手坑：直接用SET NX EX，容易忘了续期或释放锁。强烈建议用Redisson。

优点：自动续期，可重入，支持主从/哨兵/集群。
缺点：引入额外客户端，比原生命令重一点。
适用场景：任何需要互斥的分布式操作。

场景三：计数器 & 限流器

业务场景

统计页面PV、接口调用次数、短信发送频率控制。

固定窗口限流（最简单的实现）

public boolean isAllowed(String userId) {
    String key = "rate:sendSms:" + userId;
    Long count = redisTemplate.opsForValue().increment(key);
    if (count == 1) {
        redisTemplate.expire(key, 60, TimeUnit.SECONDS);
    }
    return count <= 5;  // 每分钟最多5次
}

优点：原子操作，性能极高。
缺点：固定窗口存在临界突刺（边界处可能两倍流量）。更严格的可用滑动窗口（ZSET实现）。
适用场景：API限流、短信验证码、登录错误次数。

场景四：排行榜 / 有序集合

业务场景

游戏积分榜、热搜榜单、销量排行。

使用Sorted Set

// 添加玩家分数
redisTemplate.opsForZSet().add("rank:game:202605", "player:1001", 9980);
redisTemplate.opsForZSet().add("rank:game:202605", "player:1002", 10200);

// 获取前三名（降序）
Set<ZSetOperations.TypedTuple<String>> top3 =
    redisTemplate.opsForZSet().reverseRangeWithScores("rank:game:202605", 0, 2);

优点：自动排序，查询极快（O(logN)）。
缺点：内存占用随数据量线性增长。
适用场景：实时排行榜、热点文章、商品热销榜。

场景五：最新动态 / 时间线

业务场景

微博时间线、Feed流、最新评论。

使用List（左侧推入，右侧截取）

// 发表一条新动态
String feedKey = "feeds:user:" + userId;
redisTemplate.opsForList().leftPush(feedKey, JSON.toJSONString(post));
// 只保留最近100条
redisTemplate.opsForList().trim(feedKey, 0, 99);

优点：写入快，分页方便。
缺点：无法做复杂排序，且只能按时间倒序。
适用场景：简单的“最新N条”列表，如用户动态、通知。

场景六：社交关系（集合运算）

业务场景

共同关注、好友推荐、可能认识的人。

// 用户A关注的人
redisTemplate.opsForSet().add("follow:1001", "1002", "1003", "1004");
// 用户B关注的人
redisTemplate.opsForSet().add("follow:1002", "1003", "1005");

// 共同关注
Set<String> intersect = redisTemplate.opsForSet().intersect("follow:1001", "follow:1002");
// 推荐关注（B关注但A未关注）
Set<String> diff = redisTemplate.opsForSet().difference("follow:1002", "follow:1001");

优点：集合运算毫秒级，代码简洁。
缺点：大key（比如千万粉丝）会导致慢查询。
适用场景：社交关系、权限标签、黑白名单。

场景七：轻量级消息队列（Stream / List）

业务场景

异步处理、削峰填谷、日志收集。

使用Redis 5.0+ Stream（支持消费组）

// 生产者
Map<String, String> msg = new HashMap<>();
msg.put("orderId", "ORD-123");
redisTemplate.opsForStream().add("order:stream", msg);

// 消费者
List<MapRecord<String, Object, Object>> records =
    redisTemplate.opsForStream().read(Consumer.from("order-group", "c1"),
        StreamReadOptions.empty().count(10),
        StreamOffset.create("order:stream", ReadOffset.lastConsumed()));

优点：无需额外组件，支持ACK、消费者组。
缺点：持久化可靠性不如RocketMQ/Kafka。
适用场景：内部任务分发、异步通知、不要求严格有序的场景。

场景八：布隆过滤器（防缓存穿透）

业务场景

拦截恶意请求，过滤肯定不存在的数据，避免打到数据库。

使用Redisson布隆过滤器

RBloomFilter<String> bloom = redissonClient.getBloomFilter("filter:productId");
bloom.tryInit(1000000L, 0.01); // 容量100万，误判率1%
// 初始化时把合法ID加入
for (Long id : allProductIds) {
    bloom.add(id.toString());
}

// 查询前先过滤
if (!bloom.contains(productId.toString())) {
    return null;  // 直接返回空，不查DB
}

优点：内存占用极小（1亿条仅约120MB）。
缺点：有误判率（宁可错杀一千，不放过一个）。
适用场景：防止恶意穿透、爬虫IP去重、黑名单过滤。

场景九：轻量级NoSQL（Hash存储对象）

业务场景

存储动态属性、用户Session、配置信息。

// 存储用户信息
Map<String, String> user = new HashMap<>();
user.put("name", "张三");
user.put("age", "28");
redisTemplate.opsForHash().putAll("user:1001", user);

// 获取单个字段
String name = (String) redisTemplate.opsForHash().get("user:1001", "name");
// 修改单个字段
redisTemplate.opsForHash().put("user:1001", "age", "29");

优点：比JSON序列化整个对象更节省内存，支持部分更新。
缺点：hash结构不适合深层次嵌套。
适用场景：用户资料、购物车（field为商品ID，value为数量）。

场景十：数据去重 / 唯一性判断

业务场景

UV统计、不能重复参加的抽奖、防重复提交。

使用Set或HyperLogLog

// 方式1：Set（精确但内存大）
Boolean success = redisTemplate.opsForSet().add("draw:202605", userId);
if (Boolean.TRUE.equals(success)) {
    // 第一次参加
}

// 方式2：HyperLogLog（内存极小，有误差）
redisTemplate.opsForHyperLogLog().add("uv:20260501", userId);
Long uv = redisTemplate.opsForHyperLogLog().size("uv:20260501");

优点：Set保证绝对精确；HyperLogLog内存极省（12KB）。
缺点：HyperLogLog有0.81%误差，不适合精确计数。
适用场景：抽奖去重、日活统计、爬虫URL去重。

场景十一：延时队列（使用Sorted Set）

业务场景

订单30分钟未支付自动取消、延迟通知。

// 添加延时任务（score为执行时间戳）
long execTime = System.currentTimeMillis() + 30 * 60 * 1000;
redisTemplate.opsForZSet().add("delay:order", orderId, execTime);

// 消费者定时扫描
Set<String> tasks = redisTemplate.opsForZSet().rangeByScore("delay:order", 0, System.currentTimeMillis());
for (String orderId : tasks) {
    // 处理超时订单
    if (redisTemplate.opsForZSet().remove("delay:order", orderId) > 0) {
        cancelOrder(orderId);
    }
}

优点：精准到毫秒，实现简单。
缺点：需要定时轮询，数据量大时性能下降。
适用场景：订单超时、定时提醒、会话过期清理。

更多项目实战在Java突击队网：susan.net.cn/project

总结

Redis不是只能做缓存。

当你遇到以下问题时，可以优先想想Redis：

• 快不快？ → 缓存、计数器
• 要不要排队？ → 消息队列
• 要不要去重？ → 集合、布隆过滤器
• 要不要按分数排名？ → Sorted Set
• 多机器抢资源？ → 分布式锁

下面是一张速查表，方便你回忆：

场景	数据结构	核心命令
缓存	String	GET/SET
分布式锁	String + Redisson	SET NX / tryLock
计数器	String	INCR
排行榜	ZSET	ZADD, ZREVRANGE
最新动态	List	LPUSH, LTRIM
共同关注	Set	SINTER, SDIFF
消息队列	Stream	XADD, XREADGROUP
布隆过滤	-> Redisson	RBloomFilter
对象存储	Hash	HMSET, HGET
UV去重	HyperLogLog	PFADD, PFCOUNT
延时队列	ZSET	ZADD, ZRANGEBYSCORE

最后，送大家一句话：Redis的数据结构就是你的武器库，用对结构，往往能事半功倍。

希望这11个场景能帮你打开思路，下次面试时遇到“Redis能做什么”的问题，你可以自信地展开聊上十分钟。