Spring Boot操作Redis实战指南：从Jedis到分布式锁与缓存优化

1. 写在前面的项目概述

先把这个项目到底做了什么说清楚。很多人学Redis的时候，习惯用命令行工具redis-cli把玩一通，SET、GET敲得飞起，但一回到真实项目里就懵了——Java代码里到底该怎么连Redis？Spring Boot项目里为什么Redis的key变成了一堆乱码？分布式锁到底用Redis怎么做才靠谱？这个项目就是围绕“在Java中以及Spring环境下操作Redis”这条主线展开的，把这些坑一个一个填掉，最终沉淀出一套可以直接抄进业务代码里的实践方案。

这个内容适合谁来参考？我把话放这儿：如果你是一个刚接触Spring Boot、想在项目里引入Redis做缓存或分布式锁的Java开发，这篇内容能帮你少走至少两周弯路；如果你已经用了Redis但经常遇到序列化、key乱码、缓存一致性这类问题，这里也整理了对应的定位思路和排查技巧。整篇内容不搞教科书式的知识点罗列，而是按照我实际搭过的项目流程来讲，每一步都有理由，每一段都有踩坑记录。

我知道现在的Redis相关文章满天飞，但大多数要么只讲单机命令，要么只贴配置文件然后说“配好了”，至于为什么这么配、遇到问题怎么查，一概不提。这篇不一样，我会从为什么要引入Redis说起，一直讲到在Java里用Jedis和Lettuce直连、在Spring Boot里用RedisTemplate和StringRedisTemplate、缓存注解的快速落地，以及分布式锁和缓存一致性这些高频面试和实战场景，尽量把每个环节的“为什么”也讲透。

2. Java原生操作Redis的方案选型

2.1 为什么优先推荐Jedis和Lettuce

在Spring把Redis集成好之前，Java程序要操作Redis，绕不开两个客户端库：Jedis和Lettuce。这两个都是目前Java生态里最主流的Redis客户端，Spring Data Redis底层默认用的是Lettuce，但很多老项目和个人练习项目仍然用Jedis。它们的区别不能光看名字，得从连接模型说起。

Jedis的设计很直观，它就是直连Redis服务器，每次操作都走一次TCP连接。这种模式的好处是简单，命令的发送和响应非常直接，特别适合初学者理解Redis的请求响应模型。但缺点也很致命：如果每次操作都新建连接，在高并发场景下连接开销会成为瓶颈。所以用Jedis的时候，几乎总是要配一个连接池，让一组连接反复复用，而不是用完就丢。

Lettuce则完全换了一套思路。它基于Netty实现，一个连接可以异步处理多个请求，连接是共享的，多个线程可以共用一个连接实例。这意味着即使你不搞连接池，它在很多场景下也能扛住并发压力。Spring Boot从2.x开始默认集成Lettuce，不是没道理的——它更契合响应式编程和业务量波动较大的互联网场景。

那到底选哪个？我的建议是：如果只是学习原理、做小工具，Jedis加连接池足够；如果是正经的Spring Boot项目，直接用Spring Data Redis默认的Lettuce就好，不用纠结。说白了，等你把Spring Boot的封装用熟了，大多数情况下根本不需要直接碰这两个库，但理解它们能帮你搞清楚底层链路到底发生了什么。

2.2 用Jedis快速上手连接与基础操作

为了让你先建立手感，我先用Jedis写一个最简单的例子。引入依赖只需要一个坐标：

xml复制<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>5.1.0</version>
</dependency>

然后写一段能直接跑的代码：

java复制import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class JedisQuickStart {

    public static void main(String[] args) {
        // 连接池配置：大部分参数用默认值即可，调大maxTotal应对高并发
        JedisPoolConfig config = new JedisPoolConfig();
        config.setMaxTotal(20);
        config.setMaxIdle(10);
        config.setMinIdle(2);

        // 参数含义：host, port, timeout, password
        try (JedisPool pool = new JedisPool(config, "127.0.0.1", 6379, 3000, null)) {
            try (Jedis jedis = pool.getResource()) {
                jedis.set("blog:title", "Redis in Java");
                System.out.println(jedis.get("blog:title"));
            }
        }
    }
}

这里有一处非常关键但不显眼的细节：我把获取Jedis对象写在了try-with-resources里面。很多初学者习惯手动jedis.close()，如果忘记关闭，连接池里的连接会越吃越少，最后连接耗尽，整个应用卡死。使用try-with-resources之后，即使中间的Redis命令抛异常，连接也会被归还到连接池里，这是一个很重要的好习惯。

2.3 原生Jedis的局限性

用Jedis直接写业务代码，用得爽是真爽，但很快就难受了。比如你往Redis里存了一个Java对象，怎么办？Redis本身只认字符串，你得先把对象转成JSON字符串，取出来再解析回对象。这个“序列化”的活如果纯粹用手写，每换一个业务类就要写一遍序列化和反序列化逻辑，很快代码就烂成一锅粥。

再比如，你在代码里手动管理key的拼接。今天写user:123，明天写user_123，后天别人写user-123，一个业务里出现三套命名，调试的时候想骂人。更麻烦的是，如果你在多个地方操作同一个key，很容易出现忘了设置过期时间导致数据膨胀，或者覆盖了不该覆盖的数据。

这些痛点恰恰是Spring Data Redis要解决的。它给Redis操作包了一层模板方法，把序列化、连接管理、异常转换都封装掉了，让开发者专注于业务本身。所以我在实际项目里几乎不直接使用Jedis做业务开发，它更多被我用在写工具、做测试脚本或者排查Redis本身的问题时。真正舒服的姿势，是进入Spring环境。

3. Spring环境下操作Redis的底层设计

3.1 Spring Data Redis到底帮我们做了什么

Spring Data Redis是Spring生态操作Redis的官方方案，它的核心思想可以用一个词概括：模板。就像JdbcTemplate封装了JDBC的样板代码一样， RedisTemplate封装了连接获取、命令发送、结果集映射、异常处理这一整套流程。你不需要关心用的是什么客户端，不需要关心连接怎么管理，只需要写好业务规则，RedisTemplate帮你把Redis的命令翻译出来。

但这个封装是有代价的，最大的代价就是序列化机制。RedisTemplate默认使用JdkSerializationRedisSerializer，它会把Java对象序列化成二进制字节流再存进Redis。用redis-cli去看这些数据，你就会看到一串以\xAC\xED\x00\x05开头的东西，也就是传说中的“乱码”。这其实是JDK序列化之后的二进制内容，Redis能存，Java也能读出来，但你在命令行里根本没法直观地查看和调试，而且其他语言如Python、Node.js读这些数据更是无从下手。

所以但凡涉及业务数据的存取，我几乎都会换成StringRedisSerializer存JSON字符串。这个操作很多人都知道，但代码怎么写、为什么要在RedisConfig里配一个Bean而不是直接在用到的地方传入，背后的原因值得展开说。

3.2 RedisTemplate和StringRedisTemplate的区别

Spring Boot里有两个现成的模板类，别看名字只差一个String，它们的分工完全不同。

StringRedisTemplate是RedisTemplate的子类，它把key和value的序列化器都强制设成了StringRedisSerializer，专门用来处理字符串类型的数据。它适合存“简单”的值，比如验证码、计数器、临时标记。RedisTemplate则更通用，默认是JDK序列化，你可以通过配置让它支持JSON、Jackson、Fastjson等各种序列化方案，处理对象、集合等复杂结构。

在实际开发里，我的习惯是这样的：对于简单的缓存键值，用StringRedisTemplate，干净利落；对于需要缓存Java对象的场景，自定义一个RedisTemplate的Bean，key用String序列化避免乱码，value用GenericJackson2JsonRedisSerializer，这样存进Redis的是合法JSON字符串，既方便用命令行排查，又方便跨语言读取。

3.3 RedisConfig配置类的标准写法

下面直接贴一份我常用的配置类，每行都有它的用意：

java复制import com.fasterxml.jackson.annotation.JsonAutoDetect;
import com.fasterxml.jackson.annotation.PropertyAccessor;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);

        // key使用String序列化：防止出现乱码key，方便命令行排查
        StringRedisSerializer stringSerializer = new StringRedisSerializer();
        template.setKeySerializer(stringSerializer);
        template.setHashKeySerializer(stringSerializer);

        // value使用GenericJackson2JsonRedisSerializer：自动带上类型信息，反序列化不丢类型
        GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer();
        template.setValueSerializer(jsonSerializer);
        template.setHashValueSerializer(jsonSerializer);

        template.afterPropertiesSet();
        return template;
    }
}

注意最后一行template.afterPropertiesSet()，这行代码的作用是让模板根据已设置的序列化器重新初始化内部属性。如果你漏掉这一行，后续注入使用时，RedisTemplate可能还是默认配置，序列化器的修改没有完全生效。这个细节很多人不知道，等排查问题时抓瞎半天，就是因为它。

可能有人会问，GenericJackson2JsonRedisSerializer和Jackson2JsonRedisSerializer有什么区别？区别在于一个带类型信息，一个不带。带类型信息意味着你把一个User对象存进去后，反序列化时能还原成User对象；不带的话，它默认还原成LinkedHashMap，用起来要多一步手动转换。所以我在大多数场景下更推荐Generic版本。

4. 核心实操：Spring Boot项目中Redis的完整接入

4.1 环境准备与依赖引入

在动手写代码之前，先把环境理清楚。首先是Redis本身，Windows上建议用WSL或Redis官方提供的MSI包，macOS用HomeBrew最方便，Linux直接用包管理器。启动Redis后，用redis-cli ping如果能得到PONG，说明Redis就绪。

然后是一个Spring Boot工程，这里不纠结具体版本，Spring Boot 2.x和3.x在Redis集成上的体验基本一致。核心依赖只有一个：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

如果你还需要连接池，可能需要额外引入commons-pool2依赖，但这不是必须的。Lettuce默认自带连接管理能力，对于大多数业务的并发量完全够用。

4.2 application.yml配置解析

Spring Boot的自动配置已经帮我们做了大量工作，配置文件只需声明连接信息：

yaml复制spring:
  data:
    redis:
      host: 127.0.0.1
      port: 6379
      password:
      database: 0
      timeout: 5s
      lettuce:
        pool:
          max-active: 20
          max-idle: 10
          min-idle: 2

这里有几个容易被忽略的细节。database默认是0，Redis一共有16个库，不同业务可以用不同库做逻辑隔离，但正式项目我更推荐使用不同的key前缀来做隔离，因为cluster模式不支持多库。timeout是连接超时时间，建议设置，否则Redis挂了之后请求会一直阻塞等待。lettuce.pool配置只在使用连接池时才生效，如果不想用连接池，这段可以直接不写。

4.3 用RedisTemplate实现缓存对象和过期时间管理

配置搞定之后，来看实际业务操作。假设我们要缓存一个用户的登录信息，User对象长这样：

java复制public class User {
    private Long id;
    private String name;
    private Integer age;
    // 省略getter和setter
}

用上面自定义的RedisTemplate，操作代码非常直白：

java复制import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

@Service
public class UserCacheService {

    private final RedisTemplate<String, Object> redisTemplate;

    public UserCacheService(RedisTemplate<String, Object> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    private static final String USER_KEY_PREFIX = "user:info:";

    public void cacheUser(User user) {
        String key = USER_KEY_PREFIX + user.getId();
        // 第三个参数是过期时间，这里设置30分钟
        redisTemplate.opsForValue().set(key, user, 30, TimeUnit.MINUTES);
    }

    public User getUser(Long userId) {
        Object value = redisTemplate.opsForValue().get(USER_KEY_PREFIX + userId);
        return value == null ? null : (User) value;
    }

    public void deleteUser(Long userId) {
        redisTemplate.delete(USER_KEY_PREFIX + userId);
    }
}

这里要重点说说过期时间。set(key, user, 30, TimeUnit.MINUTES)这行代码，如果漏掉了时间和单位，写成redisTemplate.opsForValue().set(key, user)，那这个key就变成了永不过期。生产环境几十个key还好，几百万个key都不过期，Redis内存迟早被打爆。所以我在代码里有一个不成文的规矩：凡是写进Redis的数据，必须显式声明过期时间，除非有特殊的持久化需求，否则一律不给长命key的机会。

还有一个很实用的类型是Hash，它在存储对象的多个字段时特别好用。比如一个用户对象有id、name、age三个字段，用Hash存就是三个field，你可以单独更新某个字段而不影响其他字段，这在缓存“热点对象部分字段更新”的场景里非常常见。RedisTemplate里对应的方法是opsForHash()，使用起来同样简单：

java复制redisTemplate.opsForHash().put("user:hash:1001", "name", "张三");
redisTemplate.opsForHash().put("user:hash:1001", "age", "18");
Object name = redisTemplate.opsForHash().get("user:hash:1001", "name");

4.4 缓存注解：用@Cacheable简化缓存逻辑

如果说RedisTemplate是手工作坊，那Spring Cache注解就是流水线。它把“查缓存、命中返回、未命中查库、回填缓存”这一整套逻辑抽象成了声明式注解，代码里一个注解就能搞定。

基础用法长这样，给Service的方法加上注解：

java复制import org.springframework.cache.annotation.Cacheable;
import org.springframework.cache.annotation.CacheEvict;
import org.springframework.stereotype.Service;

@Service
public class ProductService {

    @Cacheable(value = "product", key = "#id")
    public Product getProductById(Long id) {
        // 模拟数据库查询
        System.out.println("查询数据库: " + id);
        return new Product(id, "商品" + id);
    }

    @CacheEvict(value = "product", key = "#id")
    public void updateProduct(Long id) {
        // 更新数据库逻辑
    }
}

但用注解之前，必须在启动类或配置类上添加@EnableCaching，否则注解只是摆设。这个开关漏掉的概率非常大，因为Spring Boot不会主动开启缓存注解功能，我见过好几个同事代码里写满@Cacheable，跑起来却每次都查数据库，最后发现是没加@EnableCaching。

注解方案最大的问题是“隐式”，它把缓存逻辑藏在了注解里，出问题时不直观。比如缓存击穿、缓存雪崩怎么用注解解决？那就得在配置里设置cache-names、cache的TTL、空值缓存等参数。所以我的建议是：简单查询用@Cacheable很香，涉及复杂缓存策略、多级缓存、手动更新Redis的场景，直接用RedisTemplate更可控。两个方案并不互斥，可以混用。

4.5 直连Redis排查：可视化管理工具与命令行

不管代码写得再好，总有需要直接看Redis里到底存了什么的时候。命令行工具redis-cli是底线技能，至少要学会这几个命令：keys查看key列表，get查看字符串值，type查看key类型，ttl查看剩余生存时间。但生产环境千万别用keys *，它会阻塞Redis实例，数据量大的时候会造成卡顿，正确做法是用scan命令游标遍历。

图形化工具则在排查时能大幅提升效率。市面上的选择不少，像Redis Desktop Manager、Another Redis Desktop Manager、Redis Insight都有各自的特点。我的个人喜好是Another Redis Desktop Manager，开源免费，跨平台支持好，中文界面做得不错。图形化工具最大的价值在于连接多个Redis实例、树形浏览key、查看序列化后的JSON内容，非常直观。

5. 典型实战一：Redis分布式锁的落地细节

5.1 为什么需要分布式锁

JVM单体内的锁，比如synchronized和ReentrantLock，只能锁住当前应用实例内的线程。当应用部署成多实例，比如两台服务器同时处理请求，一个在A机器，一个在B机器，它们各自有各自的锁，互不感知，就能同时进入临界区，这就会带来超卖、重复扣款等问题。

Redis分布式锁的思路其实很朴素：用一个全局唯一的key作为锁标志，谁先把key写进Redis，谁就拿到锁；用完或者超时后删除key，其他人才能继续争抢。Redis天生单线程处理命令，SETNX（SET if Not eXists）的原子性让它成了实现分布式锁的自然选择。

5.2 从单命令到原子操作的演进

第一版分布式锁的代码可能长这样：

java复制if (redisTemplate.opsForValue().setIfAbsent("lock:order", "1")) {
    // 业务逻辑
    redisTemplate.delete("lock:order");
}

这个版本有三个明显问题。第一，如果业务逻辑执行过程中抛了异常，finally没写，锁就永远不会释放。第二，如果业务逻辑执行时间太长，锁的过期时间到了，锁自动释放，但业务还在跑，另一个线程拿到了锁，造成并发冲突。第三，删除锁时没有校验持有者，A线程的锁过期后B线程加了锁，然后A线程的finally里去删锁，把B的锁误删了。

所以一个稍微健壮的分布式锁，要同时解决原子加锁、超时自动释放、锁归属校验和原子解锁。直接照搬Redisson里的经典写法，加锁用setIfAbsent配合过期时间，这本身就是一条原子命令，Redis高版本支持一次调用完成“设置值+设置过期时间”，不用分两步，避免中间崩溃导致锁无过期时间。解锁则需要配合Lua脚本，保证“先校验再删除”这两个操作的原子性。

Spring Data Redis中可以用DefaultRedisScript来执行Lua脚本，核心思路分两步：先get锁里的value，如果是自己线程的标识，才执行del。这个标识可以用UUID加线程ID生成，确保机器维度加线程维度都唯一。

5.3 Redisson：面向生产环境的锁方案

如果项目里真的需要分布式锁，我其实不太建议自己手写。自己写的锁要考虑续期问题、可重入问题、主从切换丢锁问题，复杂度远超表面那几行代码。Redisson是Redis官方推荐的Java客户端扩展库，它内置了分布式锁的高级实现，用法极其简单：

xml复制<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>3.27.2</version>
</dependency>

java复制@Autowired
private RedissonClient redissonClient;

public void order() {
    RLock lock = redissonClient.getLock("lock:order");
    try {
        if (lock.tryLock(3, 30, TimeUnit.SECONDS)) {
            // 业务逻辑
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

Redisson里最值得一提的机制是看门狗。默认情况下，一个锁的leaseTime是30秒，但Redisson会启动一个后台任务，在锁快要过期时自动续期，直到业务执行完毕。这样就解决了“业务时间太长，锁被自动释放”的核心痛点。我在这里必须说一句：业务代码里的finally块无论如何都要执行解锁操作，而且要判断当前线程是否真的持有锁再释放，这是无数生产事故换来的经验。

5.4 分布式锁使用中的翻车案例

我见过一个非常典型的事故：某团队给库存扣减加了分布式锁，但只在扣减库存的那一个方法加锁，上层查询库存、校验参数、创建订单这些环节都没加锁。结果在极端并发下，两个请求都通过了库存校验，再分别进入扣减方法，锁形同虚设。这个事故告诉我们，分布式锁的粒度是在整个业务操作上，不是在某一个方法上。你要锁的是“整个操作过程”，不是一个“片段”。

还有一次，团队把锁的过期时间设置成了2秒，但业务逻辑因为调用外部接口偶尔会跑3秒。结果锁提前过期，另一个线程进入临界区，数据直接错乱。这个问题的根治方案是用Redisson的看门狗续期，或者把过期时间设置得足够长并配合兜底校验。如果你坚持手写，务必要想清楚过期时间设多少，还要预留一定的余量。

6. 典型实战二：缓存穿透、击穿、雪崩与数据一致性

6.1 三个高频缓存问题的区分

缓存穿透、缓存击穿、缓存雪崩这三兄弟经常被放在一起说，但它们的成因和解决方案完全不同，分不清楚会让人在面试和实际排查中都很难受。

缓存穿透是指查询一个必然不存在的数据。比如用id=-1去查询用户，数据库里没有，缓存里也没有，每次请求都要穿透缓存打到数据库。恶意攻击只需要疯狂构造不存在的id，数据库就会被拖垮。解决方案之一是缓存空值，即使数据库查不到也把空结果缓存一段时间，这样后续请求不会被放行到数据库；之二是布隆过滤器，把所有可能存在的数据id提前预加载到布隆过滤器里，查询前先经过过滤器判断id是否存在，不存在的直接拦截。

缓存击穿是指某个热点缓存key在失效瞬间，大量请求同时发现缓存没有数据，于是一起涌入数据库。这个跟穿透的区别在于，击穿针对的是“单个热点key”，它冷的时候所有请求都不命中。常见的解法是用互斥锁保证只有一个线程去查询数据库，其他线程等待这个线程回填缓存后再从缓存读。也可以用逻辑过期策略，在value里存一个逻辑过期时间，异步线程负责刷新过期数据，这样用户永远不会在热key过期的那一瞬间打到数据库。

缓存雪崩则是指大量缓存key同时过期，或者Redis实例直接宕机，导致海量请求涌向数据库。针对同时过期的问题，可以给key的过期时间加上随机值，打散整体过期时间；针对Redis宕机的问题，要上高可用架构，比如主从哨兵、集群模式。但说实话，任何缓存方案都挡不住数据库本身被流量打死，所以服务降级、限流兜底也是必须考虑的。

6.2 缓存与数据库的一致性策略

缓存和数据库的数据可能不一致，这是缓存设计里最让人头疼的问题。业界有两个方向：Cache Aside模式和延迟双删，它们各有适用范围。

Cache Aside模式是指在读请求中先读缓存，缓存未命中再读数据库并回填缓存；写请求中先更新数据库，再删除缓存。为什么是删除缓存而不是更新缓存？因为更新缓存需要把数据库里的新值经过复杂计算写入缓存，成本高，而且在高并发写入同一个key时，先写缓存A后写缓存B，很容易出现时序错乱导致缓存里存的是旧值。删除缓存则更简单，下一次读请求发现缓存没了，重新从数据库加载，数据就是最新的。

延迟双删其实是对Cache Aside的一个补充。具体操作是：先删除缓存，再更新数据库，然后等待几百毫秒，再次删除缓存。为什么要删两次？因为在高并发下，请求A更新数据库前的删除缓存操作完成后，请求B读到了数据库的旧数据回填缓存，然后请求A才更新数据库，这就有个时间窗口，缓存里是旧数据。第二次删除就是为了干掉这个窗口期回填的脏数据。这个方案在低并发下够用，但它并不能百分之百保证一致性，主要用在数据一致性要求不那么苛刻但又要兼顾性能的业务中。

6.3 项目里的实际取舍经验

在真实的业务项目里，我不会为了追求最终一致性去上重度方案。对大部分业务来说，缓存允许短暂不一致，只要在一秒级的时间窗口内收敛就好。所以我采用的是折中策略：核心交易数据不缓存或者缓存时间极短，展示型数据用缓存并设置合适的过期时间，配合延迟双删兜底。在数据一致性要求极高且并发量也非常大的场景，我才考虑引入Canal监听MySQL的binlog来异步更新Redis缓存，那是另一个层面的架构设计了。

还有一点必须提醒，缓存过期时间的设计一定不要拍脑袋。比如展示型数据的过期时间，不能所有key都写同一个固定值，否则就容易变成雪崩。我给每个业务模块一个基准过期时间，比如商品信息30分钟，用户信息1小时，配置信息5分钟，再在所有key的过期时间上叠加一个1秒到5分钟的随机数，这样整体的过期分布就非常均匀。

6.4 缓存监控与预警

把Redis接入项目之后，如果完全不去监控它，迟早会在一个深夜被报警电话叫醒。我在项目里通常会盯几个核心指标：内存使用率、key数量、命令执行速率、慢查询日志。Redis自身提供的INFO命令可以一次拿回大量运行数据，配合Spring Boot Actuator暴露的Redis健康指标，可以做一个基本的监控面板。

慢查询这块要特别留意。Redis的slowlog get命令能查看到执行时间超过阈值的命令，默认阈值是10毫秒。如果发现大量KEYS *命令出现在慢查询列表里，基本可以断定是代码里用了不合理的操作，必须改成SCAN或者直接优化key设计。我见过有人用Redis存了百万级的key，然后在业务代码里用KEYS user:*去匹配所有用户缓存做批量操作，结果Redis CPU飙升，整个业务链路的响应时间跟着涨，这类事故在监控上看一眼慢查询就能定位。

7. 常见问题排查与避坑记录

7.1 连接超时与连接池耗尽

Redis连接超时是高频问题。现象通常是应用日志里出现RedisConnectionFailureException或者Cannot get Jedis connection。排查思路分四步走：第一步，确认Redis进程是否活着，用redis-cli ping即可；第二步，确认网络是否通，尤其是跨机房部署的Redis，用telnet ip 6379验证端口连通性；第三步，确认配置的密码和账号是否正确，Redis默认没有密码，但如果你配置了requirepass，那么客户端必须带上密码；最后，检查连接池参数，如果max-active设置太小，而并发量又大，连接就可能被耗尽。我建议在项目里设置一个合理的max-active值，同时开启连接池的block-when-exhausted策略，让请求在连接池耗尽时等待而不是直接报错。

7.2 乱码key与空值序列化的坑

乱码key的根源我之前提过，就是RedisTemplate默认的JDK序列化。它的表现是Redis里存的key长这样：\xAC\xED\x00\x05t\x00\tuser:1。如果项目已经跑了一段时间，想纠正这个问题的成本很高，因为直接改序列化器会导致旧数据读不出来。稳妥的切换方式是：先用StringRedisTemplate或者命令行导出所有需要保留的数据，在低峰期升级配置并做数据迁移。如果只是新项目，从一开始就配置好StringRedisSerializer和GenericJackson2JsonRedisSerializer就完事了，一天坑都不用踩。

还有一个特别隐蔽的问题：如果value序列化器配置了Jackson，但你要缓存的类里没有无参构造函数，反序列化时会抛异常。Java对象Jackson反序列化默认是调用无参构造函数创建对象再逐个赋值，如果你只写了带参构造函数，反序列化会直接失败。解决办法是显式添加无参构造器，或者在类上通过Jackson注解指定反序列化工厂。这个小问题能卡住很多人排查一整晚。

7.3 缓存命中率不理想

缓存命中率低，第一个要查的就是key是否稳定。如果你把时间戳拼进了key，比如user:info:1001:20250101000000，那这个key永远只有一个请求能命中，后续的请求都在查新的不存在的key。检测方式很简单，Redis的INFO stats命令会返回keyspace_hits和keyspace_misses两个指标，命中率小于80%就要警惕key设计的问题了。

另一个常见原因是缓存预热缺失。如果系统刚启动，或者业务刚上线，缓存里空空如也，即便数据量很小，第一次查询也要打数据库。针对这种情况，可以在项目启动后执行预热任务，把热点数据提前加载到Redis里。做法有很多，比如实现ApplicationRunner接口，或者在启动监听器中调用一次查询逻辑，让自然的缓存逻辑先把热点数据回填，效果都还不错。

7.4 事务与Pipeline的取舍

Redis本身支持事务，用MULTI和EXEC包裹多条命令可以保证它们按顺序执行，但Redis事务不同于关系型数据库，它不支持回滚，只能保证“批量执行不被插入其他命令”。在Spring Data Redis中使用SessionCallback可以把多条命令放在同一个连接里执行，这在需要保证多个操作原子性时会用到。但要注意，Redis事务在cluster模式下有较多限制，跨槽位的key没法在同一个事务里操作。

Pipeline则完全是另一种思路，它把多个命令一次性发给Redis，Redis执行完后统一返回结果。它的价值是减少网络往返次数，在批量写入大量key时效果显著。比如批量缓存1000个商品信息，用Pipeline可以把耗时从十几次网络往返压缩到一两次。但Pipeline不是事务，它只是批量发送命令，中间命令出错不会回滚。我一般在做“缓存预热”“数据导入”这类场景时使用Pipeline，业务核心链路里反而用得少，因为它的调试相对困难。

7.5 常见问题速查表

为了方便日常排查，我把实际工作中最常遇到的问题整理成一张对照表，你可以直接拿来当速查手册。

7.6 从一次生产事故看排查思路

分享一个我印象比较深的真实事故。某天下午，我们有个服务的接口响应时间突然从50毫秒涨到5秒，监控里看到Redis的CPU使用率接近100%。第一反应是Redis被大量慢命令打满了，于是执行slowlog get 20，发现清一色是KEYS user:*。追溯代码后发现，是上线的某个定时任务，“为了清空一批用户缓存再重新加载”，直接用了KEYS匹配出几千个key，然后批量删除。

这种操作的坑在于，KEYS命令会遍历整个Redis的key空间，数据量越大耗时越长，而且它是在Redis主线程里执行的，一个KEYS就能把整个Redis的读写全部阻塞住。修复方案很简单：把这个定时任务改成用SCAN游标分批遍历key，或者直接用Lua删除匹配的key，但SCAN加删除的组合最直观。这个事故给我的教训是：在Redis里，任何“全量扫描”的操作都值得警惕，能用精确key操作就绝不用模式匹配。

8. 序列化器选型与性能对比

8.1 常见序列化方案的横向对比

在Redis场景下，序列化器不仅影响存储格式，还直接影响读写性能和存储空间。我用过的方案主要有JDK、Jackson JSON、Fastjson、Kryo和Protobuf，它们各有适用场景。

JDK序列化的优点是Java原生支持，不用额外引入依赖，类实现了Serializable就能用；缺点是体积大、速度慢、可读性差。Redis里存同样的一个User对象，JDK序列化后的字节数可能比JSON多一倍以上，这在存储大量缓存时会显著浪费内存。Jackson JSON的优点是存储可读、跨语言兼容好，GenericJackson2JsonRedisSerializer还能带上类型信息；缺点是反序列化需要反射，吞吐量不如二进制格式。Fastjson因为一直有安全漏洞的历史，我基本不在新项目里用了。Kryo和Protobuf在性能和体积上都有优势，但Redis的使用场景往往还需要跨语言读取，二进制格式的调试成本很高，除非你有非常极致的性能需求，否则我不推荐日常业务引入。

8.2 我推荐的组合

在绝大多数Spring Boot项目中，我会选择StringRedisSerializer处理key，GenericJackson2JsonRedisSerializer处理value。这两个组合的优点是：key是明文，排查起来直观；value是JSON文本，前端、Python脚本、命令行都能直接看懂；自带类型信息，反序列化不丢失类型。代价是性能和二进制方案有一定差距，但对绝大多数业务来说，毫秒级访问Redis已经不是性能瓶颈，序列化器的开销完全可接受。

如果你对性能有更高要求，可以先让Redis存压缩后的字符串。比如在写入前用GZIP对JSON字符串做一次压缩，在读取后解压再解析。这个方案能大幅降低Redis的内存和网络开销，代价是CPU占用会上升，好在Redis访问的性能瓶颈很少在CPU上。我在一个每日几亿请求的查询场景里实测过，压缩后Redis的存储量降低了约70%，整体响应时间不升反降，因为网络传输量小了。

8.3 序列化配置对兼容性的影响

有件事必须提前想清楚：序列化方案的改动会导致旧数据无法解析。比如你原来用的是JDK序列化，突然切到JSON序列化，Redis里存量数据都是老的二进制格式，JSON反序列化器根本读不了。所以序列化器的变更一定要结合数据迁移策略来设计。我建议在Redis的key前缀里带上版本号或者业务标识，比如v2:user:info:1001，这样新旧数据能共存，等到旧 key自然过期后，再逐步清理旧的序列化数据。这种做法看起来有点笨，但它在真实项目里是最稳的演进方式。

9. 写在最后的实操体会

这个项目做下来，我对Redis在Java和Spring环境下的使用有了一个相对完整的认知闭环。从手工敲Jedis命令，到用Spring Data Redis模板，再到封装缓存注解和分布式锁，每一步都是顺着真实的业务需求走出来的，不是为了用技术而用技术。我的体会是：Redis本身并不复杂，复杂的是它和业务结合后产生的那些边界问题，比如序列化、锁失效、缓存一致性。这些问题光靠背面试题是解决不了的，必须亲手踩一次坑才能建立肌肉记忆。

最后分享一个小技巧：无论项目用什么封装，一定要定期用redis-cli --scan --pattern去检查生产环境的key风格和过期时间分布。我每隔一两周都会扫一遍，看看有没有异常的大key、有没有不带过期时间的key、有没有命名风格不一致的key。累计下来，这个习惯救了我好几次，很多隐患都是在它们变成事故之前就被提前发现的。

Redis是一个越用越觉得简单的工具，但越深入越能感受到它在细节里的深水区。希望这篇文章能帮你少踩几个我当年踩过的坑，也欢迎在实际操作中遇到问题回来对照速查表定位思路。项目做完了，但优化和迭代的路还很长，后续有新的踩坑经验我再来补充。