Redis基础

上一篇我们完成了Redis全体系复盘与面试精讲，把整个系列的知识点闭环收尾。但很多刚入门的同学仍会疑惑：数据库、本地缓存、消息队列已经能满足需求，为什么还要额外引入Redis？

其实Redis并非“锦上添花”的组件，而是高并发、高性能系统的刚需中间件。它凭借亚毫秒级响应、丰富数据类型、多场景适配、高可用部署四大优势，完美解决了传统组件的性能瓶颈。本篇聚焦后端最常用的缓存、队列、计数器三大核心场景，讲透“为什么用Redis”以及“怎么用Redis”，帮你彻底理解Redis的核心价值。

核心结论：Redis是“全能型”内存中间件，一份部署满足多场景需求，相比专用组件更轻量、更高效，是中小团队和高并发业务的首选。

一、场景一：分布式缓存（Redis最核心用途）

1. 为什么不用数据库/本地缓存？

  • 数据库瓶颈：磁盘IO速度慢，高并发查询下极易被打垮，不适合高频读场景
  • 本地缓存瓶颈：单机存储、无法共享，集群环境下数据不一致，扩容困难
  • Redis优势：内存读写+分布式部署，QPS可达10万+，缓存命中率轻松突破95%，完美分担数据库压力

2. 缓存场景落地实战

核心用法：热点数据缓存（商品详情、用户信息、配置参数）

// 缓存+数据库双读伪代码（标准缓存套路）
public UserInfo getUserInfo(Long userId) {
    String key = "user:info:" + userId;
    // 第一步：查Redis缓存
    UserInfo cacheUser = redisTemplate.opsForValue().get(key);
    if (cacheUser != null) {
        return cacheUser;
    }
    // 第二步：缓存未命中，查数据库
    UserInfo dbUser = userMapper.selectById(userId);
    if (dbUser != null) {
        // 第三步：写入Redis，设置过期时间防止脏数据
        redisTemplate.opsForValue().set(key, dbUser, 2, TimeUnit.HOURS);
    }
    return dbUser;
}

3. 缓存场景关键要点

  • 适用数据：读多写少、不频繁变更的热点数据
  • 避坑提醒：做好穿透、击穿、雪崩防护，设置合理过期时间与淘汰策略
  • 收益：数据库压力降低90%以上，接口响应速度从数百毫秒降至毫秒级

二、场景二：轻量级消息队列（低成本解耦异步）

1. 为什么不用专业MQ（Kafka/RocketMQ）？

  • 专业MQ痛点：部署重、运维复杂、学习成本高，中小业务场景“大材小用”
  • Redis优势：无需额外部署，利用List、Stream数据类型即可实现队列，轻量易用、延迟极低，满足异步解耦、削峰需求

2. 队列场景落地实战

方案1：List实现简单队列（生产消费模型）

// 生产者：向队列推送消息
public void pushMessage(String message) {
    String key = "redis:queue:order";
    redisTemplate.opsForList().leftPush(key, message);
}

// 消费者：阻塞式拉取消息（避免空轮询）
@Scheduled(fixedDelay = 100)
public void consumeMessage() {
    String key = "redis:queue:order";
    // 阻塞等待，超时时间5秒
    String message = redisTemplate.opsForList().rightPop(key, 5, TimeUnit.SECONDS);
    if (message != null) {
        // 执行业务逻辑：订单处理、日志上报等
        processMessage(message);
    }
}

方案2：Redis Stream（生产级可靠队列）

Redis 5.0+推出Stream类型，支持消息持久化、消费者组、ACK确认、回溯消费，媲美专业MQ，适合对可靠性有要求的场景。

3. 队列场景适用范围

  • 适用场景：日志上报、订单异步处理、短信推送、数据同步等非核心强可靠场景
  • 局限性：不适合百万级消息堆积、严格事务消息、超长延迟队列
  • 收益：一键实现异步解耦，削峰填谷，避免同步请求阻塞主线程

三、场景三：高性能计数器（高并发计数神器）

1. 为什么不用数据库计数？

  • 数据库瓶颈：频繁update计数语句，行锁竞争激烈，高并发下性能极差
  • Redis优势：单线程原子操作，无锁竞争，incr/incrBy命令性能爆表，支持分布式计数、实时统计

2. 计数器场景落地实战

核心用法：点赞数、阅读量、库存、接口限流、日活统计

// 1. 文章阅读量计数（原子自增）
public Long incrementReadCount(Long articleId) {
    String key = "article:read:" + articleId;
    // 原子自增，线程安全，高并发无压力
    return redisTemplate.opsForValue().increment(key);
}

// 2. 商品库存扣减（防超卖）
public Boolean deductStock(Long goodsId, Integer count) {
    String key = "goods:stock:" + goodsId;
    // 原子减库存，返回剩余库存
    Long remainStock = redisTemplate.opsForValue().decrement(key, count);
    if (remainStock < 0) {
        // 库存不足，回滚
        redisTemplate.opsForValue().increment(key, count);
        return false;
    }
    return true;
}

// 3. 接口限流计数（单位时间内请求次数）
public Boolean limitRequest(String userId, String apiPath) {
    String key = "request:limit:" + userId + ":" + apiPath;
    // 1分钟内最多访问60次
    Long count = redisTemplate.opsForValue().increment(key);
    if (count == 1) {
        // 首次请求设置过期时间
        redisTemplate.expire(key, 1, TimeUnit.MINUTES);
    }
    return count <= 60;
}

3. 计数器场景核心优势

  • 原子性：所有计数命令都是原子操作，分布式环境下无并发安全问题
  • 高性能：单节点每秒可支撑数十万次计数操作，远超数据库
  • 易扩展：配合过期时间实现周期计数（日、周、月统计），无需复杂逻辑

四、三大场景对比：Redis为什么是最优解？

场景传统方案痛点Redis优势核心命令/类型
分布式缓存数据库慢、本地缓存不一致内存高速读写、分布式共享String/Hash、set/get
轻量队列专业MQ部署重、运维成本高轻量无部署、低延迟、易上手List/Stream、lpush/rpop
高性能计数器数据库锁竞争、性能差原子操作、无锁、高并发String、incr/decr

一句话总结：一份Redis部署，同时搞定性能提速（缓存）、异步解耦（队列）、并发计数（计数器），性价比拉满，这就是Redis成为后端标配的根本原因。

五、引入Redis的注意事项

  • 做好高可用部署：主从+哨兵或Cluster集群，避免单机宕机影响全业务
  • 内存管控：设置maxmemory、合理淘汰策略，防止内存溢出
  • 数据持久化：开启混合持久化，防止重启丢数据
  • 权限管控：设置强密码，禁止公网直接访问，防范安全风险

结语

Redis从来不是“为了用而用”，而是精准解决了高并发系统的三大核心痛点：读性能不足、同步阻塞、并发计数难。缓存、队列、计数器这三大场景，覆盖了后端80%的业务需求，吃透这些用法，既能提升系统性能，又能简化技术栈，降低运维成本。

后续我们还会基于这三大场景，拓展Redis实战进阶用法，比如分布式锁、延迟队列、热点统计等，持续输出干货内容，敬请关注～

发表回复