Redis缓存穿透、击穿、雪崩实战：从原理到高并发治理方案

做淘宝闪购SPS（秒杀促销系统）的开发，最头疼的往往不是业务逻辑本身，而是流量一上来缓存层就开始各种“整活”。CPU没涨多少，数据库连接池先被打满，紧接着就是一串告警：慢查询、连接超时、服务雪崩连锁反应。这套路我见过太多次了，而且绝大多数问题都是围绕Redis缓存的三件事：穿透、击穿、雪崩。

说个我自己的体会：这三个词在面试题里被讲烂了，但真正在项目里能把它们“治明白”的人不多。为什么？因为很多方案是纸面上的，比如“加锁”“布隆过滤器”“随机过期时间”，听着简单，落地的时候全是细节：RedisTemplate序列化方式不对、锁续期没做、布隆过滤器误判率没算、空值缓存把内存打爆……任何一个细节没注意，线上就是事故。

这篇文章我不打算搞成教科书，就按照我在闪购SPS项目里的实际处理过程来讲。从三个问题的定义和触发场景，到具体的Java实现方案、代码示例、踩坑记录，再到面试和治理层面的延伸，一条线捋下来。不管你是刚接触Redis的Java开发，还是已经在写高并发接口的老手，应该都能找到点能直接抄作业的东西。

1. 闪购场景下的缓存难题：穿透、击穿、雪崩到底是什么

很多同学对这三个概念背得滚瓜烂熟，但是一放到真实业务里就分不清了。其实你只要记住一句话：它们都是“请求打到数据库”的异常路径，只是原因和规模不一样。闪购SPS这类系统，特点就是瞬时流量高、热点商品集中、读多写少，Redis缓存是扛住压力的第一道墙，墙要是漏了，数据库就得面对几万个并发，那基本就是等死。

1.1 缓存请求的正常路径和异常路径

正常路径很简单：请求进来，先查Redis，Redis有数据就直接返回，没有就去数据库查，查到后回填Redis，再返回给调用方。

code复制请求 -> Redis缓存 -> 命中则返回
                -> 未命中 -> 数据库 -> 回填缓存 -> 返回

这条路径在平时没问题，但闪购场景会把它放大。举个例子，一个限量款商品在10点开抢，假设有10万用户同时刷新商品详情页，Redis里正好没有这个key（比如刚上线还没人访问过），10万个请求就会同时穿透到数据库。数据库连接池就50个，结果就是连接超时、接口报错，用户体验直接从“抢不到”变成“系统崩了”。

异常路径分三种：穿透、击穿、雪崩。我习惯用一句话概括：

• 缓存穿透：查了一个根本不存在的数据，缓存和数据库都没有，每次请求都白打数据库。
• 缓存击穿：查了一个热点key，缓存突然失效，大量并发同时去数据库重建数据。
• 缓存雪崩：大量key同时失效，或者Redis直接宕机，导致所有请求全部打到数据库。

1.2 用生活场景快速区分三个概念

拿食堂打饭来类比，理解起来特别快。

• 穿透：食堂菜单上有个不存在的菜（比如“红烧狮子头炖榴莲”），每个来打饭的同学都问一遍“有没有这个菜”，食堂阿姨每次都要去后厨翻一遍冰箱，然后说没有。后厨被问烦了，真正的菜也没时间做了。
• 击穿：食堂最火的招牌菜（红烧肉）有个大铁锅，平时做好一锅放着。结果这锅菜卖完了，重新做需要10分钟。这时候排队等着吃红烧肉的人，全都趴在窗口问“好了没”，后厨连其他菜都顾不上炒了。
• 雪崩：食堂集中停电，所有灶台都停了，所有菜都做不了。不管你想吃啥，都得等，食堂瞬间瘫痪。

这三个问题在闪购SPS里会同时出现甚至互相叠加。比如秒杀开始时，活动商品详情是热点key，刚到过期时间，又碰上黑产用不存在的商品ID疯狂扫描，击穿+穿透一起来，数据库不挂才怪。所以治理的时候不能只堵一个坑，要一起考虑。

2. 缓存穿透：恶意请求和无效数据如何打垮数据库

先说说我遇到的一次线上事故。某个大促活动，我们SPS系统里有一个查询商品详情的接口，接收商品ID，逻辑很简单：先查Redis，再查数据库。结果活动开始后两天，数据库的QPS突然从500涨到8000，CPU直接100%，好几个从库被打爆。查了日志发现，有个调用方在循环请求一些不存在的商品ID，而且每次ID都不同，Redis里永远查不到，全部打到了数据库。

这就是典型的缓存穿透。正常的穿透流量我们不谈，最怕的就是这种恶意扫描，或者业务方传错参数（比如前端把商品ID传成了0或者负数），一旦被高频调用，数据库压力瞬间拉满。

2.1 第一道防线：参数校验不能省

很多同学觉得参数校验是“low活”，不就是在Controller里加几个if吗？但穿透治理恰恰要从这里开始。闪购系统里商品ID一般是long类型，有业务规则：必须大于0，必须属于某个店铺，状态必须是上架。好的做法是进入缓存查询之前，先做一层合法性校验：

java复制public ProductVO getProductDetail(Long productId, Long shopId) {
    // 第一层：参数合法性校验
    if (productId == null || productId <= 0 || shopId == null || shopId <= 0) {
        throw new BizException(ErrorCode.INVALID_PARAM);
    }
    // 第二层：业务规则校验（比如商品是否属于该店铺）
    if (!productService.checkProductBelongShop(productId, shopId)) {
        throw new BizException(ErrorCode.PRODUCT_NOT_FOUND);
    }
    // 第三层：缓存与存储查询
    String key = "sps:product:detail:" + productId;
    String json = redisTemplate.opsForValue().get(key);
    if (StringUtils.hasText(json)) {
        return JSON.parseObject(json, ProductVO.class);
    }
    // ...
}

别小看这一步。一个非法的ID直接在业务逻辑层被拒绝，根本不会进入Redis和数据库，天然挡住了大部分“手滑”和初级的脚本扫描。

2.2 第二道防线：空值缓存

校验挡不住的情况是：ID合法但是数据库里找不到记录。比如商品被下架了，或者数据库里确实没有这个ID，但外部系统还在持续调用。这时候缓存里也没有，数据库也查不到，怎么办？

最经典也最实用的方案：空值缓存。也就是把“查不到”这个结果本身也缓存到Redis里，设置一个比较短的过期时间。代码大概长这样：

java复制public ProductVO getProductDetail(Long productId) {
    String key = "sps:product:detail:" + productId;
    String json = redisTemplate.opsForValue().get(key);
    
    // 如果命中缓存，直接返回
    if (StringUtils.hasText(json)) {
        return JSON.parseObject(json, ProductVO.class);
    }
    
    // 缓存中有空标记，直接返回null
    if (CACHE_NULL_VALUE.equals(json)) {
        return null;
    }
    
    // 缓存未命中，查数据库
    Product product = productMapper.selectById(productId);
    if (product != null) {
        redisTemplate.opsForValue().set(key, JSON.toJSONString(product), 30, TimeUnit.MINUTES);
        return convertToVO(product);
    } else {
        // 缓存空值，TTL设置为2-3分钟，防止恶意流量打穿
        redisTemplate.opsForValue().set(key, CACHE_NULL_VALUE, 3, TimeUnit.MINUTES);
        return null;
    }
}

这段代码里有几个细节非常关键。

第一，空值缓存的TTL不能太长。3分钟是一个比较合理的值，太短挡不住突发流量，太长会导致真实的商品上架后用户看到的还是“不存在”。我之前见过有人直接把空值缓存设置成24小时，结果运营上架了商品，用户端还是一直显示“商品已下架”，排查了半天才发现是空值缓存没删。

第二，空值缓存一定要跟正常缓存区分开。我是用一个约定的字符串常量 CACHE_NULL_VALUE = "NULL_VALUE"，然后在读取的时候要做判断，不能让空标记直接序列化出去当成正常数据。有些同事偷懒，直接缓存空字符串，结果前端拿到的就是 ""，还得再处理一次。

第三，要注意内存问题。如果一个恶意脚本同时扫描100万个不存在的ID，空值缓存就会占用100万个key，按每个key 200字节算，大约200MB内存。这个成本在大多数公司是可以接受的，但如果扫描量极大，就得考虑加布隆过滤器。

2.3 第三道防线：布隆过滤器

布隆过滤器是穿透治理的进阶方案，原理一句话：通过多个哈希函数，把元素映射到一个很长的bit数组中。判断一个元素“一定不在集合中”是准确的，但判断“在集合中”可能误判（把不存在的判断成存在）。所以在缓存查询之前，先用布隆过滤器挡掉大部分肯定不存在的ID。

我用的是Guava的BloomFilter，初始化的时候把所有上架商品ID放进去。代码示例：

java复制@Component
public class ProductBloomFilter {
    private static final int EXPECTED_INSERTIONS = 1_000_000; // 预期插入量，根据商品总量调整
    private static final double FPP = 0.01; // 误判率，越小越占内存

    private final BloomFilter<Long> bloomFilter;

    public ProductBloomFilter() {
        this.bloomFilter = BloomFilter.create(Funnels.longFunnel(), EXPECTED_INSERTIONS, FPP);
    }

    @PostConstruct
    public void init() {
        // 系统启动时加载所有上架商品ID，或者定期异步刷新
        List<Long> productIds = productMapper.selectAllOnSaleIds();
        productIds.forEach(bloomFilter::put);
    }

    public boolean mightContain(Long productId) {
        return bloomFilter.mightContain(productId);
    }

    public void addProduct(Long productId) {
        bloomFilter.put(productId);
    }
}

然后在查询逻辑里加一步：

java复制if (!productBloomFilter.mightContain(productId)) {
    // 布隆过滤器判断一定不存在，直接返回
    return null;
}

这里的参数怎么定？布隆过滤器的误判率和位数组大小有一个公式：m = - (n * ln(p)) / (ln(2)^2)，其中m是bit数组长度，n是插入元素个数，p是误判率。比如100万商品ID，误判率1%，算下来大约需要 m = - (1000000 * ln(0.01)) / (0.6931^2) ≈ 9,585,058 bit，也就是大约1.14MB。每个元素还需要约 k = (m/n) * ln(2) ≈ 7 个哈希函数。Guava会帮你算好这些，你只需要传入预期数量和误判率就行。

不过布隆过滤器也不是银弹。它有一个很麻烦的问题：不能删除元素。如果商品下架了，你没法把对应的bit清掉，只能重新构建过滤器。所以我在项目里是启动时全量加载+每5分钟增量加入新上架ID+凌晨定期重建，保证过滤器的数据不过期。

注意：布隆过滤器适合“数量比较稳定”的场景，如果你的商品ID池变动频繁，初始化成本和误判影响会变大，需要评估后再用。

3. 缓存击穿：热点key过期瞬间的并发风暴

击穿这个问题在闪购场景里特别典型。我们有个秒杀活动，活动当天0点开始，10点开抢。运营会在10点前把活动商品的详情信息预热到Redis，过期时间设置的是开抢前1分钟，也就是09:59过期。设计意图是：过期后重新从数据库拉最新的库存和价格，保证数据准确。

结果到了09:59那一瞬间，10万用户正在疯狂刷新商品详情页，Redis缓存刚过期，10万个请求同时落到数据库。数据库瞬间被打到连接池满，然后服务开始超时报错，紧接着其他依赖数据库的接口也崩了。

这就是缓存击穿：一个热点key，在过期的瞬间，大量请求并发打到数据库。

3.1 方案一：互斥锁（业界最常用）

互斥锁的思路很好理解：缓存过期后，不是所有请求都去查数据库，而是只有一个请求去重建缓存，其他请求等待，等缓存重建好了，直接从Redis获取。实现方式可以用Redis的SETNX命令，或者用Redisson的分布式锁。

我用RedisTemplate实现一个简单的版本：

java复制public ProductVO getProductDetailWithLock(Long productId) {
    String key = "sps:product:detail:" + productId;
    String lockKey = "sps:product:lock:" + productId;
    
    // 1. 先查缓存
    String json = redisTemplate.opsForValue().get(key);
    if (StringUtils.hasText(json)) {
        return JSON.parseObject(json, ProductVO.class);
    }
    
    // 2. 缓存未命中，尝试获取分布式锁
    String requestId = UUID.randomUUID().toString();
    Boolean locked = redisTemplate.opsForValue()
            .setIfAbsent(lockKey, requestId, 5, TimeUnit.SECONDS);
    
    if (Boolean.TRUE.equals(locked)) {
        try {
            // 3. 拿到锁后，再查一次缓存（双检），防止在等待锁的过程中缓存已经被重建
            json = redisTemplate.opsForValue().get(key);
            if (StringUtils.hasText(json)) {
                return JSON.parseObject(json, ProductVO.class);
            }
            
            // 4. 真正查数据库
            Product product = productMapper.selectById(productId);
            if (product != null) {
                redisTemplate.opsForValue().set(key, JSON.toJSONString(product), 30, TimeUnit.MINUTES);
            } else {
                redisTemplate.opsForValue().set(key, CACHE_NULL_VALUE, 3, TimeUnit.MINUTES);
            }
            return convertToVO(product);
        } finally {
            // 5. 释放锁，只释放自己的锁
            String lockValue = redisTemplate.opsForValue().get(lockKey);
            if (requestId.equals(lockValue)) {
                redisTemplate.delete(lockKey);
            }
        }
    }
    
    // 6. 没拿到锁，说明有其他线程在重建缓存，短暂等待后重试
    try {
        Thread.sleep(50);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
    return getProductDetailWithLock(productId); // 递归重试，也可以改成循环
}

这里有几个容易踩的坑，我一个个说。

第一个坑：锁的误删问题。如果释放锁的时候直接 redisTemplate.delete(lockKey)，有可能把别人刚获取的锁删掉。因为一个线程在持锁期间如果执行时间超过锁过期时间，锁已经自动释放了，另一个线程又重新获取到了锁，这时候第一个线程执行完，直接把锁删了，就把第二个线程的锁误删了。解决办法就是代码里写的：释放前先比对value，只删除自己设置的那个值。

第二个坑：锁过期时间设置太短。如果查询数据库和回填缓存的逻辑超过了锁的过期时间（比如数据库慢查询需要3秒，你锁设置了2秒），那锁就失效了，起不到互斥作用。生产环境建议用Redisson的 RLock，它带看门狗自动续期，默认每10秒续期一次，不用担心锁过期问题。

第三个坑：递归重试的压测问题。如果数据库真的挂了，每个请求都拿不到锁，就会一直递归重试，CPU直接被打满。所以我后来把递归改成了for循环，并且限制了最大重试次数：

java复制public ProductVO getProductDetailWithLockRetry(Long productId) {
    int maxRetry = 3;
    for (int i = 0; i < maxRetry; i++) {
        ProductVO vo = getProductDetailWithLock(productId);
        if (vo != null) {
            return vo;
        }
        try {
            Thread.sleep(20 * (i + 1));
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
    // 最后兜底：直接查数据库（这里可以做降级处理）
    return loadFromDatabase(productId);
}

3.2 方案二：逻辑过期（适合极其热点的key）

互斥锁会让部分请求短暂等待，虽然只有几十毫秒，但对于追求极致体验的场景还不够。闪购SPS里有一种更高级的玩法：逻辑过期。简单说，缓存里存的数据永远不过期（物理上不设TTL），但是value里带一个逻辑过期时间字段。每次读取的时候校验逻辑时间，如果过期了，就异步去重建缓存，当前请求仍然返回旧数据。

示例代码：

java复制public class ProductCacheWrapper {
    private String data;      // 商品数据JSON
    private long expireTime;  // 逻辑过期时间戳
    private long cacheTime;   // 缓存写入时间戳
    
    // getter/setter省略
}

public ProductVO getProductDetailLogicalExpire(Long productId) {
    String key = "sps:product:detail:logical:" + productId;
    String json = redisTemplate.opsForValue().get(key);
    if (StringUtils.hasText(json)) {
        ProductCacheWrapper wrapper = JSON.parseObject(json, ProductCacheWrapper.class);
        if (wrapper.getExpireTime() > System.currentTimeMillis()) {
            // 逻辑判断未过期，直接返回
            return JSON.parseObject(wrapper.getData(), ProductVO.class);
        }
        // 逻辑过期，发起异步重建
        asyncRebuildCache(productId, key);
        // 当前请求返回旧数据
        return JSON.parseObject(wrapper.getData(), ProductVO.class);
    }
    // 缓存不存在，走同步重建（或者直接查库）
    return loadFromDatabase(productId);
}

@Async
public void asyncRebuildCache(Long productId, String key) {
    // 这个异步方法里可以用分布式锁保证只有一个线程重建
    String lockKey = "sps:product:rebuild:lock:" + productId;
    boolean locked = tryLock(lockKey);
    if (!locked) {
        return; // 其他线程已经在重建了
    }
    try {
        Product product = productMapper.selectById(productId);
        ProductCacheWrapper wrapper = new ProductCacheWrapper();
        wrapper.setData(JSON.toJSONString(convertToVO(product)));
        wrapper.setCacheTime(System.currentTimeMillis());
        wrapper.setExpireTime(System.currentTimeMillis() + 30 * 60 * 1000L);
        redisTemplate.opsForValue().set(key, JSON.toJSONString(wrapper));
    } finally {
        unlock(lockKey);
    }
}

逻辑过期的优势是：请求永远不等待，用户体验不会出现卡顿。坏处是：数据一致性变差了，用户可能看到最多30分钟前的旧数据。在闪购场景里，如果库存数据是逻辑过期，超卖风险会变大。所以我建议：详情页、图片、描述这种“弱一致”数据用逻辑过期；库存、价格这种“强一致”数据还是用互斥锁靠数据库兜底。

3.3 方案三：热点key永不过期+主动更新

这是最简单粗暴的办法：热点key不设过期时间，通过一个定时任务在后台定期更新缓存。可以理解成“缓存是活的，自己会更新自己”。

java复制// 定时任务：每30秒刷新一次热点商品缓存
@Scheduled(fixedDelay = 30_000)
public void refreshHotProductCache() {
    List<Long> hotProductIds = hotProductService.getHotProductIds();
    for (Long productId : hotProductIds) {
        String key = "sps:product:detail:" + productId;
        Product product = productMapper.selectById(productId);
        if (product != null) {
            redisTemplate.opsForValue().set(key, JSON.toJSONString(convertToVO(product)));
        }
    }
}

这个方案的好处是完全没有击穿的问题，因为key根本不会过期。坏处是需要维护一个热点列表，而且更新频率不能太高，否则数据库压力也不小。实际项目中我通常是“永不过期+逻辑过期”结合：线上热点商品永不过期，后台任务每30秒更新一次，更新前判断一下商品是否有变更（通过binlog或者版本号）。这种架构在电商大促里很成熟，面试聊到这时候可以重点展开。

4. 缓存雪崩：大面积缓存失效与Redis宕机

雪崩和击穿的区别在于范围。击穿是一个key失效，雪崩是多个key或者全部key失效。闪购SPS里常见的雪崩诱因有两个：一是活动预热时把所有商品的缓存设置了相同的过期时间，零点一起过期；二是Redis集群发生故障（比如主节点宕机、网络分区），导致所有缓存请求全部失败。

不管是哪种，到了数据库层面就是几万并发压过来，基本没有不挂的。

4.1 方案一：过期时间随机化

这是最便宜的雪崩治理方案。核心一句话：不要让大量key在同一时间过期。做法是在设置缓存的时候，给TTL加一个随机偏移量。

java复制// 原始做法：所有商品统一过期
redisTemplate.opsForValue().set(key, json, 30, TimeUnit.MINUTES);

// 改进做法：TTL在30分钟基础上随机加1-300秒
int baseExpire = 30 * 60;
int randomExpire = ThreadLocalRandom.current().nextInt(300);
redisTemplate.opsForValue().set(key, json, baseExpire + randomExpire, TimeUnit.SECONDS);

为什么随机偏移量能防雪崩？因为每个key的过期时间点被打散后，同一时刻过期的key数量会大幅减少。比如100个key，原本都在10:00:00过期；加上随机偏移后，它们在10:00:00到10:05:00之间陆续过期，数据库在每个时间点只需要处理几个key的缓存重建，压力可以忽略不计。

这个操作的成本几乎为零，但是收益非常明显。我之前在项目里推动过这个改造，只改了公共的缓存工具类，所有业务方自动生效，没有再发生过因为批量过期导致的数据库尖刺。

4.2 方案二：多级缓存（本地缓存+Redis）

Redis挂了，不代表系统就只能死。我们可以在应用进程内再加一层本地缓存，也就是二级缓存：请求先查本地Caffeine，查不到再查Redis，Redis再查不到才查数据库。这样即使Redis整个不可用，只要能命中本地缓存，接口还是能正常返回。

简化代码示例：

java复制@Component
public class ProductLocalCache {
    private final Cache<String, ProductVO> caffeineCache;

    public ProductLocalCache() {
        this.caffeineCache = Caffeine.newBuilder()
                .maximumSize(10_000)      // 最多缓存1万个商品
                .expireAfterWrite(30, TimeUnit.SECONDS) // 本地缓存30秒过期
                .build();
    }

    public ProductVO get(String key) {
        return caffeineCache.getIfPresent(key);
    }

    public void put(String key, ProductVO vo) {
        caffeineCache.put(key, vo);
    }
}

然后在查询接口里串联起来：

java复制public ProductVO getProductDetailMultiLevel(Long productId) {
    String key = "sps:product:detail:" + productId;
    
    // 第一级：本地缓存
    ProductVO localVo = localCache.get(key);
    if (localVo != null) {
        return localVo;
    }
    
    // 第二级：Redis
    String json = redisTemplate.opsForValue().get(key);
    if (StringUtils.hasText(json)) {
        ProductVO vo = JSON.parseObject(json, ProductVO.class);
        localCache.put(key, vo);
        return vo;
    }
    
    // 第三级：数据库
    ProductVO vo = loadFromDatabase(productId);
    if (vo != null) {
        String finalJson = JSON.toJSONString(vo);
        redisTemplate.opsForValue().set(key, finalJson, 30, TimeUnit.MINUTES);
        localCache.put(key, vo);
    }
    return vo;
}

多级缓存要注意数据一致性问题。本地缓存只有30秒的有效期，所以Redis里数据更新后，本地缓存最多有30秒的延迟。在闪购场景里，商品详情这种弱一致数据还好；但是库存数据不能这么搞，否则可能出现超卖。所以建议：库存相关的接口不走本地缓存，或者本地缓存只缓存“用户维度的非关键数据”。

4.3 方案三：Redis高可用和限流降级

你说缓存雪崩是Redis挂了导致的？那就要从架构上保证Redis不挂。我们常用的手段：

• Redis主从+哨兵模式，或者直接上Redis Cluster，保证一个节点宕机后能自动切换。
• 给Redis配置合理的maxmemory和淘汰策略（比如allkeys-lru），防止内存被打满后触发OOM。
• 多集群隔离，把核心业务（订单、库存）和非核心业务（商品详情、推荐）拆到不同的Redis集群，避免互相影响。

除此之外，应用层也要做兜底。比如Sentinel或者Hystrix的熔断降级：当Redis的可用性指标（比如错误率超过20%）达到阈值时，触发熔断，直接走本地缓存或者降级默认值，不调用Redis，给Redis恢复的时间。这块我之前在项目里用过Sentinel的熔断规则，配置代码如下：

yaml复制# application.yml 示例片段
sentinel:
  datasource:
    flow:
      rules:
        - resource: "getProductDetail"
          grade: 2  # 熔断降级（异常比例）
          count: 0.2 # 异常比例超过20%
          timeWindow: 30 # 熔断30秒

熔断后，系统会快速失败，而不是无限等待Redis超时。然后每次熔断窗口结束后放行一个试探请求，如果Redis恢复了，就关闭熔断。这个机制保障了数据库不会被失效的Redis拖垮。

5. Redis热点Key问题与常见的过期时间设计

在闪购SPS里，除了三大经典问题，还有一个我强烈建议单独拎出来说的：热点Key问题。它和击穿很像，但又不完全一样。一个key被大量请求访问，即使缓存没有过期，Redis单实例也会变成瓶颈。比如同一件爆款商品，QPS达到每秒10万，所有请求都集中在这一个key上，那这个key所在的Redis分片CPU和网卡很容易打满，形成单点热点。

5.1 热点Key的识别和处理

识别热点Key有几个办法：一是Redis节点上开启hotkey分析，比如使用redis-cli --hotkeys扫描；二是通过Redis的monitor命令采样，看看哪些key被频繁访问；三是直接在应用层埋点统计，比如用Sentinel或者Micrometer统计每个key的访问次数。

处理方案我实测下来比较有效的是本地缓存+读写分散。

本地缓存前面已经说过，这里不重复。读写分散稍微复杂一点：给热点key加后缀，拆成多个子key，分发到不同Redis分片。比如一个商品的key是 sps:product:detail:1001，热点之后可以拆成：

code复制sps:product:detail:1001:0
sps:product:detail:1001:1
sps:product:detail:1001:2

请求进来的时候，对请求的某个标识（比如用户ID）取模，均匀访问其中一个子key。写的时候需要同步更新所有子key。这个方案能有效分散单key的访问压力，但会带来一致性和维护成本的上升，非万不得已不推荐。

5.2 过期时间的科学设计

关于过期时间，很多人都是拍脑袋设一个“30分钟”。但在闪购场景，这个值非常讲究。设得太短，缓存命中率低，数据库压力大；设得太长，数据时效性差，用户看到的价格/库存不准确。我的做法是分类设置：

另外一个很容易忽略的点：在缓存更新的时候，要主动设置一个合理的过期时间。有些同学写代码的时候只调set(key, value)，发现不好使才想起加过期时间。我建议封装一个统一的缓存工具类，默认所有key都要求传TTL，强制大家养成好习惯。比如：

java复制public void setWithExpire(String key, String value, int ttlSeconds) {
    // 默认加上随机偏移，防止雪崩
    int random = ThreadLocalRandom.current().nextInt(Math.min(ttlSeconds / 10, 60));
    redisTemplate.opsForValue().set(key, value, ttlSeconds + random, TimeUnit.SECONDS);
}

这样一个简单的封装，就把“随机过期时间”落地到了所有业务代码里，不用每个地方自己加随机数。

6. 实战避坑：RedisTemplate的序列化与increment()报错实录

写到这里，插一段特别实用的问题排查记录。很多人在Java里用RedisTemplate，会踩一个非常经典的坑：increment()方法报错ERR value is not an integer or out of range。网上搜到的答案五花八门，但90%的原因是序列化方式不一致。

6.1 increment()报错的根因

RedisTemplate默认的序列化器是JdkSerializationRedisSerializer，存入的数据是带一串二进制类型的Java序列化对象，而不是纯字符串。当你调用increment()去对一个之前用opsForValue().set(key, 1)写入的key做自增时，Redis底层执行INCR命令，会尝试把这个二进制数据转换成整数，结果发现不是合法的整数格式，就抛出上述错误。

解决办法很简单：给RedisTemplate设置StringRedisSerializer。

java复制@Configuration
public class RedisConfig {
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        
        // key使用String序列化
        StringRedisSerializer stringSerializer = new StringRedisSerializer();
        template.setKeySerializer(stringSerializer);
        template.setHashKeySerializer(stringSerializer);
        
        // value使用Jackson序列化，方便跨语言读取
        GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer();
        template.setValueSerializer(jsonSerializer);
        template.setHashValueSerializer(jsonSerializer);
        
        template.afterPropertiesSet();
        return template;
    }
}

或者更简单一点，直接用StringRedisTemplate，它的key和value都是String序列化，完全避开了这个问题。如果业务上value里存的是对象，那就用JSON.toJSONString()转成字符串再存，取出时再反序列化。我后来在项目里统一用StringRedisTemplate+手动JSON序列化的方式，虽然多写几行代码，但是排查问题的时候太省心了，Redis Desktop Manager里看到的都是普通人能看懂的数据，而不是\xAC\xED\x00\x05t\x00这种天书。

6.2 缓存工具类的正确封装方式

分享一个我生产环境一直在用的缓存工具类片段，把序列化、空值标记、随机过期都整合进去：

java复制@Component
public class CacheService {
    private static final String NULL_MARK = "NULL_VALUE";
    
    @Resource
    private StringRedisTemplate stringRedisTemplate;

    public <T> T get(String key, Class<T> clazz) {
        String json = stringRedisTemplate.opsForValue().get(key);
        if (StringUtils.isEmpty(json)) {
            return null;
        }
        if (NULL_MARK.equals(json)) {
            return null;
        }
        return JSON.parseObject(json, clazz);
    }

    public void set(String key, Object value, int ttlSeconds) {
        if (value == null) {
            stringRedisTemplate.opsForValue().set(key, NULL_MARK, Math.min(ttlSeconds, 300), TimeUnit.SECONDS);
            return;
        }
        // 加随机偏移，防雪崩
        int random = ThreadLocalRandom.current().nextInt(Math.min(ttlSeconds / 10, 60));
        stringRedisTemplate.opsForValue().set(key, JSON.toJSONString(value), ttlSeconds + random, TimeUnit.SECONDS);
    }

    public boolean tryLock(String lockKey, String requestId, long expireSeconds) {
        return Boolean.TRUE.equals(
            stringRedisTemplate.opsForValue().setIfAbsent(lockKey, requestId, expireSeconds, TimeUnit.SECONDS)
        );
    }

    public void unlock(String lockKey, String requestId) {
        String value = stringRedisTemplate.opsForValue().get(lockKey);
        if (requestId.equals(value)) {
            stringRedisTemplate.delete(lockKey);
        }
    }
}

6.3 排查Redis问题时的几个常用命令

真正排查线上问题的时候，光看业务日志是不够的，需要在Redis端确认现场。整理几个我经常用的命令：

• redis-cli -h {host} -p {port} info keyspace：查看各数据库的key数量和过期情况。
• redis-cli -h {host} -p {port} monitor：打印所有命令（慎用，生产环境高流量下会很卡）。
• redis-cli -h {host} -p {port} --bigkeys：扫描大key，排查那个key占用了大量内存。
• redis-cli -h {host} -p {port} ttl {key}：查看某个key的剩余过期时间。
• redis-cli -h {host} -p {port} --stat：周期性打印Redis运行状态，包括QPS、内存等。

有一次我们排查缓存雪崩，就是通过monitor命令发现所有商品的DEL命令同时触发了，原因是运营后台做了一次批量上架操作，把一批商品的信息全部重新写入Redis，先删了旧key，结果数据库查询还没返回，缓存是空的，流量穿透到了数据库。这个问题的根源不是随机过期没做，而是业务操作里“批量删缓存再重建”的窗口期。后来我们改成了“异步更新缓存”，先写入新值再删旧值，问题就消失了。

7. 面试官的视角：缓存三大问题怎么答出亮点

我看到热搜词里大量出现“java面试题”、“redis面试题”、“java八股文”，顺带聊聊怎么把这些内容讲出水平。面试问缓存穿透/击穿/雪崩，十个有九个能答出来定义和基础方案，但大多数人停在“布隆过滤器”“互斥锁”“随机过期时间”这种名词层面，被追问两句就卡住了。

我当面试官的时候，最想听到的是这三个层次：

第一，能说清楚区别和联系。击穿是一个热点key失效，雪崩是一批key失效，穿透是压根没有这个key。回答的时候主动画一条请求链路出来，告诉面试官问题发生在链路的哪个位置。

第二，能说出方案背后的原理和代价。比如互斥锁，你要能解释为什么要用分布式锁而不是本地锁，锁的过期时间怎么设置，拿到锁之后为什么要二次检查缓存，释放锁的时候为什么要校验requestId。这些细节比“我会用Redisson”有价值得多。

第三，能结合真实业务场景。这就是我在前面一直在强调的实战经验。比如你说闪购场景里库存数据不能用逻辑过期，因为会超卖；商品详情可以用逻辑过期，因为用户可以容忍少部分数据延迟。这些结合业务场景的思考，才是面试官想听到的亮点。

如果你能顺带讲明白RedisTemplate序列化对increment()的影响，或者批量删key导致雪崩这种事故，就更能体现你踩过坑、思考过方案，而不是只背了八股文。

8. 我在实际项目里的最终落地经验

最后说点大白话。缓存穿透、击穿、雪崩这三件事，我做了这么多年项目，最大的感悟是：没有一套方案能一劳永逸，每次活动、每个业务都要重新评估。

闪购SPS里我最终落地的组合是：

• 所有入口加参数校验，非法请求直接拒绝；
• 商品ID池用布隆过滤器做第一层过滤；
• 查询不到的数据做3分钟空值缓存；
• 普通商品缓存设置30分钟+随机过期；
• 秒杀热点商品用逻辑过期+异步刷新，库存数据用互斥锁+数据库兜底；
• Redis侧采用Cluster模式，应用侧扛不住时触发Sentinel熔断降级，本地Caffeine缓存再挡一层。

这套组合不能说100%保证数据库不被打垮，但至少在各种压测和真实大促中，我们的数据库QPS一直稳定在可控范围内。线上出过几次小问题，基本都是因为改动时忘记走统一的缓存工具类，或者某个key的过期时间被拍脑袋设置得太长/太短。所以我会强烈建议：把缓存治理的规范下沉到工具类和代码模板里，而不是靠每个开发自觉。

如果你正在做类似的高并发项目，建议按照我上面的思路，先把三大问题的危害在脑海里建模一遍，再对照自己的系统看哪一层缺失了。不要想着一步到位上很复杂的架构，从最简单、成本最低的“参数校验+空值缓存+随机过期”做起，再逐步叠加布隆过滤器和多级缓存，你会发现系统抗压力的提升非常明显。

最后再分享一个小技巧：做缓存治理改造时，一定要在压测环境里模拟“缓存刚过期+高并发”这个瞬间。用压测工具把某个热点key的过期时间调到即将触发的时间点，然后看数据库连接数的曲线。这个场景跑通了，线上大促心里就有底了。