1. Redis缓存实战从基础策略到高并发优化在电商、社交等互联网应用中缓存是提升系统性能的关键组件。作为一款高性能的内存数据库Redis凭借其丰富的数据结构和出色的读写速度成为缓存系统的首选方案。但在实际业务中简单的读取-写入缓存模式往往无法应对复杂场景本文将基于真实项目经验深入剖析Redis缓存的三大核心问题及解决方案。2. 缓存更新策略与一致性保障2.1 主动更新机制设计缓存系统的首要挑战是如何保证数据一致性。我们采用先更新数据库再删除缓存的策略这种方案在大多数场景下能有效平衡性能与一致性需求。Override Transactional public Result update(Shop shop) { Long id shop.getId(); if (id null) { return Result.fail(店铺id不能为空); } // 1.更新数据库 updateById(shop); // 2.删除缓存 stringRedisTemplate.delete(CACHE_SHOP_KEY id); return Result.ok(); }关键点必须将数据库更新和缓存操作放在同一个事务中确保原子性。如果第二步失败整个事务应该回滚。2.2 缓存查询流程优化查询时采用标准的缓存优先策略并设置合理的过期时间TTL防止长期数据不一致Override public Result queryById(Long id) { String key CACHE_SHOP_KEY id; // 1.从redis查询商铺缓存 String shopJson stringRedisTemplate.opsForValue().get(key); // 2.判断是否存在 if (StrUtil.isNotBlank(shopJson)) { // 3.存在直接返回 Shop shop JSONUtil.toBean(shopJson, Shop.class); return Result.ok(shop); } // 4.不存在根据id查询数据库 Shop shop getById(id); // 5.不存在返回错误 if (shop null) { return Result.fail(店铺不存在); } // 6.存在写入redis设置30分钟过期 stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), 30L, TimeUnit.MINUTES); return Result.ok(shop); }实践经验过期时间应根据业务特点设置高频变化数据设置较短TTL如5-10分钟低频变化数据可适当延长如1-2小时使用Jackson或FastJSON等高效序列化工具减少CPU开销对于大对象考虑采用压缩算法如Snappy减少内存占用3. 缓存穿透防护实战3.1 问题本质与危害分析缓存穿透是指查询一个根本不存在的数据导致请求直接穿透缓存层到达数据库。在恶意攻击场景下大量这类请求可能导致数据库崩溃。典型特征Redis命中率骤降数据库QPS异常升高日志中出现大量Key not found记录3.2 解决方案对比方案原理优点缺点适用场景缓存空对象将不存在的数据也缓存起来实现简单内存浪费数据范围有限的情况布隆过滤器使用概率型数据结构判断存在性内存效率高存在误判海量数据过滤3.3 空对象缓存实现public R,ID R queryWithPassThrough( String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit){ String key keyPrefix id; // 1.从redis查询缓存 String json stringRedisTemplate.opsForValue().get(key); // 2.判断是否存在 if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 3.判断是否为空值防穿透标记 if (json ! null) { return null; } // 4.查询数据库 R r dbFallback.apply(id); // 5.数据库不存在缓存空值 if (r null) { stringRedisTemplate.opsForValue().set( key, , 2L, TimeUnit.MINUTES); // 短TTL return null; } // 6.存在则正常缓存 this.set(key, r, time, unit); return r; }优化技巧空值缓存应设置较短的TTL如2-5分钟避免长期占用内存可结合IP限流等措施防止恶意攻击者不断变换Key发起请求对于明确无效的ID范围如负数可在业务层直接拦截4. 缓存雪崩预防方案4.1 问题场景还原当大量缓存同时失效或Redis节点宕机时请求洪峰直接冲击数据库导致级联故障。某电商平台曾在促销活动开始时因优惠券缓存集体过期造成数据库瞬间过载。4.2 多级防御策略4.2.1 过期时间随机化// 基础过期时间 随机偏移量0~300秒 long expireTime TimeUnit.MINUTES.toSeconds(30) ThreadLocalRandom.current().nextInt(300); stringRedisTemplate.opsForValue().set( key, value, expireTime, TimeUnit.SECONDS);4.2.2 热点数据永不过期逻辑过期Data public class RedisData { private LocalDateTime expireTime; // 逻辑过期时间 private Object data; } // 写入逻辑过期数据 public void setWithLogicalExpire(String key, Object value, Long time, TimeUnit unit) { RedisData redisData new RedisData(); redisData.setData(value); redisData.setExpireTime(LocalDateTime.now() .plusSeconds(unit.toSeconds(time))); stringRedisTemplate.opsForValue().set( key, JSONUtil.toJsonStr(redisData)); }4.2.3 熔断降级机制// 使用Resilience4j实现熔断 CircuitBreaker circuitBreaker CircuitBreaker.ofDefaults(dbCircuit); SupplierShop supplier CircuitBreaker.decorateSupplier( circuitBreaker, () - queryFromDB(id)); try { return supplier.get(); } catch (Exception e) { // 返回兜底数据 return getFallbackShop(id); }5. 缓存击穿应对方案5.1 互斥锁方案public R, ID R queryWithMutex( String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) { String key keyPrefix id; // 1.查询缓存 String json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 2.尝试获取锁 String lockKey lock: key; try { boolean isLock tryLock(lockKey); if (!isLock) { Thread.sleep(50); // 休眠后重试 return queryWithMutex(keyPrefix, id, type, dbFallback, time, unit); } // 3.再次检查缓存双重检查 json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 4.查询数据库 R r dbFallback.apply(id); if (r null) { stringRedisTemplate.opsForValue().set( key, , 2L, TimeUnit.MINUTES); return null; } // 5.写入缓存 this.set(key, r, time, unit); return r; } finally { unlock(lockKey); } }5.2 逻辑过期异步重建private static final ExecutorService CACHE_REBUILD_EXECUTOR Executors.newFixedThreadPool(10); public R, ID R queryWithLogicalExpire( String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) { String key keyPrefix id; // 1.查询缓存 String json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isBlank(json)) { return null; } // 2.解析逻辑过期时间 RedisData redisData JSONUtil.toBean(json, RedisData.class); R r JSONUtil.toBean((JSONObject) redisData.getData(), type); if (redisData.getExpireTime().isAfter(LocalDateTime.now())) { return r; // 未过期 } // 3.过期则尝试获取锁 String lockKey lock: key; if (tryLock(lockKey)) { // 4.异步重建 CACHE_REBUILD_EXECUTOR.submit(() - { try { R newR dbFallback.apply(id); this.setWithLogicalExpire(key, newR, time, unit); } finally { unlock(lockKey); } }); } return r; // 返回旧数据 }6. 工程化实践与工具类封装6.1 缓存客户端设计Slf4j Component public class CacheClient { private final StringRedisTemplate stringRedisTemplate; private static final ExecutorService CACHE_REBUILD_EXECUTOR Executors.newFixedThreadPool(10); // 基础set/get方法 public void set(String key, Object value, Long time, TimeUnit unit) { stringRedisTemplate.opsForValue().set( key, JSONUtil.toJsonStr(value), time, unit); } // 防穿透查询 public R, ID R queryWithPassThrough(...) { ... } // 互斥锁查询 public R, ID R queryWithMutex(...) { ... } // 逻辑过期查询 public R, ID R queryWithLogicalExpire(...) { ... } }6.2 业务层调用示例// 防穿透查询 Shop shop cacheClient.queryWithPassThrough( cache:shop:, id, Shop.class, this::getById, 30L, TimeUnit.MINUTES); // 热点数据查询需提前预热 cacheClient.setWithLogicalExpire( hot:product:id, product, 10L, TimeUnit.MINUTES); Product product cacheClient.queryWithLogicalExpire( hot:product:, id, Product.class, this::getProductById, 10L, TimeUnit.MINUTES);7. 性能优化与监控7.1 关键指标监控缓存命中率正常应保持在80%以上Redis内存使用率避免超过70%警戒线命令延迟P99应小于5ms连接数合理设置连接池大小7.2 实战建议键设计规范使用冒号分隔的命名空间如user:session:123避免过长的Key不超过1KB对热点Key增加随机后缀分片内存优化使用Hash结构存储对象启用内存淘汰策略volatile-lru定期分析大Keyredis-cli --bigkeys高可用保障部署Redis哨兵或集群设置合理的超时和重试机制实现本地缓存降级Caffeine在电商秒杀系统中我们通过组合使用逻辑过期和互斥锁方案成功将数据库负载降低80%QPS提升至3万/秒。关键在于根据业务特点选择合适的缓存策略并建立完善的监控体系。 
长河君 · 2026/11/5 8:20:50 · 阅读 1.2k Redis缓存策略与高并发优化实战
1. Redis缓存实战从基础策略到高并发优化在电商、社交等互联网应用中缓存是提升系统性能的关键组件。作为一款高性能的内存数据库Redis凭借其丰富的数据结构和出色的读写速度成为缓存系统的首选方案。但在实际业务中简单的读取-写入缓存模式往往无法应对复杂场景本文将基于真实项目经验深入剖析Redis缓存的三大核心问题及解决方案。2. 缓存更新策略与一致性保障2.1 主动更新机制设计缓存系统的首要挑战是如何保证数据一致性。我们采用先更新数据库再删除缓存的策略这种方案在大多数场景下能有效平衡性能与一致性需求。Override Transactional public Result update(Shop shop) { Long id shop.getId(); if (id null) { return Result.fail(店铺id不能为空); } // 1.更新数据库 updateById(shop); // 2.删除缓存 stringRedisTemplate.delete(CACHE_SHOP_KEY id); return Result.ok(); }关键点必须将数据库更新和缓存操作放在同一个事务中确保原子性。如果第二步失败整个事务应该回滚。2.2 缓存查询流程优化查询时采用标准的缓存优先策略并设置合理的过期时间TTL防止长期数据不一致Override public Result queryById(Long id) { String key CACHE_SHOP_KEY id; // 1.从redis查询商铺缓存 String shopJson stringRedisTemplate.opsForValue().get(key); // 2.判断是否存在 if (StrUtil.isNotBlank(shopJson)) { // 3.存在直接返回 Shop shop JSONUtil.toBean(shopJson, Shop.class); return Result.ok(shop); } // 4.不存在根据id查询数据库 Shop shop getById(id); // 5.不存在返回错误 if (shop null) { return Result.fail(店铺不存在); } // 6.存在写入redis设置30分钟过期 stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), 30L, TimeUnit.MINUTES); return Result.ok(shop); }实践经验过期时间应根据业务特点设置高频变化数据设置较短TTL如5-10分钟低频变化数据可适当延长如1-2小时使用Jackson或FastJSON等高效序列化工具减少CPU开销对于大对象考虑采用压缩算法如Snappy减少内存占用3. 缓存穿透防护实战3.1 问题本质与危害分析缓存穿透是指查询一个根本不存在的数据导致请求直接穿透缓存层到达数据库。在恶意攻击场景下大量这类请求可能导致数据库崩溃。典型特征Redis命中率骤降数据库QPS异常升高日志中出现大量Key not found记录3.2 解决方案对比方案原理优点缺点适用场景缓存空对象将不存在的数据也缓存起来实现简单内存浪费数据范围有限的情况布隆过滤器使用概率型数据结构判断存在性内存效率高存在误判海量数据过滤3.3 空对象缓存实现public R,ID R queryWithPassThrough( String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit){ String key keyPrefix id; // 1.从redis查询缓存 String json stringRedisTemplate.opsForValue().get(key); // 2.判断是否存在 if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 3.判断是否为空值防穿透标记 if (json ! null) { return null; } // 4.查询数据库 R r dbFallback.apply(id); // 5.数据库不存在缓存空值 if (r null) { stringRedisTemplate.opsForValue().set( key, , 2L, TimeUnit.MINUTES); // 短TTL return null; } // 6.存在则正常缓存 this.set(key, r, time, unit); return r; }优化技巧空值缓存应设置较短的TTL如2-5分钟避免长期占用内存可结合IP限流等措施防止恶意攻击者不断变换Key发起请求对于明确无效的ID范围如负数可在业务层直接拦截4. 缓存雪崩预防方案4.1 问题场景还原当大量缓存同时失效或Redis节点宕机时请求洪峰直接冲击数据库导致级联故障。某电商平台曾在促销活动开始时因优惠券缓存集体过期造成数据库瞬间过载。4.2 多级防御策略4.2.1 过期时间随机化// 基础过期时间 随机偏移量0~300秒 long expireTime TimeUnit.MINUTES.toSeconds(30) ThreadLocalRandom.current().nextInt(300); stringRedisTemplate.opsForValue().set( key, value, expireTime, TimeUnit.SECONDS);4.2.2 热点数据永不过期逻辑过期Data public class RedisData { private LocalDateTime expireTime; // 逻辑过期时间 private Object data; } // 写入逻辑过期数据 public void setWithLogicalExpire(String key, Object value, Long time, TimeUnit unit) { RedisData redisData new RedisData(); redisData.setData(value); redisData.setExpireTime(LocalDateTime.now() .plusSeconds(unit.toSeconds(time))); stringRedisTemplate.opsForValue().set( key, JSONUtil.toJsonStr(redisData)); }4.2.3 熔断降级机制// 使用Resilience4j实现熔断 CircuitBreaker circuitBreaker CircuitBreaker.ofDefaults(dbCircuit); SupplierShop supplier CircuitBreaker.decorateSupplier( circuitBreaker, () - queryFromDB(id)); try { return supplier.get(); } catch (Exception e) { // 返回兜底数据 return getFallbackShop(id); }5. 缓存击穿应对方案5.1 互斥锁方案public R, ID R queryWithMutex( String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) { String key keyPrefix id; // 1.查询缓存 String json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 2.尝试获取锁 String lockKey lock: key; try { boolean isLock tryLock(lockKey); if (!isLock) { Thread.sleep(50); // 休眠后重试 return queryWithMutex(keyPrefix, id, type, dbFallback, time, unit); } // 3.再次检查缓存双重检查 json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 4.查询数据库 R r dbFallback.apply(id); if (r null) { stringRedisTemplate.opsForValue().set( key, , 2L, TimeUnit.MINUTES); return null; } // 5.写入缓存 this.set(key, r, time, unit); return r; } finally { unlock(lockKey); } }5.2 逻辑过期异步重建private static final ExecutorService CACHE_REBUILD_EXECUTOR Executors.newFixedThreadPool(10); public R, ID R queryWithLogicalExpire( String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) { String key keyPrefix id; // 1.查询缓存 String json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isBlank(json)) { return null; } // 2.解析逻辑过期时间 RedisData redisData JSONUtil.toBean(json, RedisData.class); R r JSONUtil.toBean((JSONObject) redisData.getData(), type); if (redisData.getExpireTime().isAfter(LocalDateTime.now())) { return r; // 未过期 } // 3.过期则尝试获取锁 String lockKey lock: key; if (tryLock(lockKey)) { // 4.异步重建 CACHE_REBUILD_EXECUTOR.submit(() - { try { R newR dbFallback.apply(id); this.setWithLogicalExpire(key, newR, time, unit); } finally { unlock(lockKey); } }); } return r; // 返回旧数据 }6. 工程化实践与工具类封装6.1 缓存客户端设计Slf4j Component public class CacheClient { private final StringRedisTemplate stringRedisTemplate; private static final ExecutorService CACHE_REBUILD_EXECUTOR Executors.newFixedThreadPool(10); // 基础set/get方法 public void set(String key, Object value, Long time, TimeUnit unit) { stringRedisTemplate.opsForValue().set( key, JSONUtil.toJsonStr(value), time, unit); } // 防穿透查询 public R, ID R queryWithPassThrough(...) { ... } // 互斥锁查询 public R, ID R queryWithMutex(...) { ... } // 逻辑过期查询 public R, ID R queryWithLogicalExpire(...) { ... } }6.2 业务层调用示例// 防穿透查询 Shop shop cacheClient.queryWithPassThrough( cache:shop:, id, Shop.class, this::getById, 30L, TimeUnit.MINUTES); // 热点数据查询需提前预热 cacheClient.setWithLogicalExpire( hot:product:id, product, 10L, TimeUnit.MINUTES); Product product cacheClient.queryWithLogicalExpire( hot:product:, id, Product.class, this::getProductById, 10L, TimeUnit.MINUTES);7. 性能优化与监控7.1 关键指标监控缓存命中率正常应保持在80%以上Redis内存使用率避免超过70%警戒线命令延迟P99应小于5ms连接数合理设置连接池大小7.2 实战建议键设计规范使用冒号分隔的命名空间如user:session:123避免过长的Key不超过1KB对热点Key增加随机后缀分片内存优化使用Hash结构存储对象启用内存淘汰策略volatile-lru定期分析大Keyredis-cli --bigkeys高可用保障部署Redis哨兵或集群设置合理的超时和重试机制实现本地缓存降级Caffeine在电商秒杀系统中我们通过组合使用逻辑过期和互斥锁方案成功将数据库负载降低80%QPS提升至3万/秒。关键在于根据业务特点选择合适的缓存策略并建立完善的监控体系。