Spring Cache Redis 实战如何用缓存套餐数据减少80%数据库查询在电商和外卖系统中套餐数据往往是高频查询但低频变更的典型场景。想象一下每当用户浏览餐厅页面时系统都要反复查询数据库获取相同的套餐信息这种设计不仅浪费资源还会在流量高峰时成为性能瓶颈。本文将分享一套经过实战验证的Spring Cache与Redis整合方案通过简单的注解配置让你的系统轻松应对高并发查询。1. 环境准备与基础配置1.1 依赖引入与Redis连接首先确保项目中包含必要的依赖项。在Maven项目中除了标准的Spring Boot Starter依赖外需要特别添加这两个关键依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-cache/artifactId /dependencyRedis配置通常放在application.yml中以下是一个生产级配置示例spring: redis: host: your-redis-host port: 6379 password: your-password-if-any lettuce: pool: max-active: 20 max-idle: 10 min-idle: 5 max-wait: 3000ms1.2 启用缓存功能在Spring Boot启动类上添加EnableCaching注解是激活缓存功能的钥匙SpringBootApplication EnableCaching public class FoodDeliveryApplication { public static void main(String[] args) { SpringApplication.run(FoodDeliveryApplication.class, args); } }2. 核心缓存注解实战应用2.1 Cacheable查询缓存化这个注解是减少数据库查询的主力军。以下是一个套餐查询的典型应用GetMapping(/meals/{id}) Cacheable(value mealCache, key #id, unless #result null) public Meal getMealById(PathVariable Long id) { log.info(查询数据库获取套餐ID: {}, id); return mealRepository.findById(id).orElse(null); }关键参数说明value定义缓存名称相当于命名空间key缓存键的生成规则支持SpEL表达式unless条件过滤这里表示结果为null时不缓存2.2 CachePut更新缓存策略当套餐数据变更时我们需要同步更新缓存PostMapping(/meals) CachePut(value mealCache, key #meal.id) public Meal createMeal(RequestBody Meal meal) { return mealRepository.save(meal); }2.3 CacheEvict缓存失效处理删除或禁用套餐时需要清理对应的缓存DeleteMapping(/meals/{id}) CacheEvict(value mealCache, key #id) public void deleteMeal(PathVariable Long id) { mealRepository.deleteById(id); }对于批量操作可以使用CacheEvict(value mealCache, allEntries true) public void refreshAllMeals() { // 批量更新逻辑 }3. 高级缓存策略与优化3.1 缓存穿透防护当查询不存在的套餐ID时可能会引发缓存穿透。解决方案是缓存空结果Cacheable(value mealCache, key #id, unless #result null) public Meal getMealWithNullCache(Long id) { Meal meal mealRepository.findById(id).orElse(null); if(meal null) { // 记录不存在的键用于监控 log.warn(不存在的套餐查询: {}, id); } return meal; }3.2 缓存雪崩预防为不同的缓存项设置随机的TTL可以避免同时失效Configuration public class RedisConfig { Bean public RedisCacheManagerBuilderCustomizer redisCacheManagerBuilderCustomizer() { return builder - builder .withCacheConfiguration(mealCache, RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofMinutes(30 new Random().nextInt(15)))); } }3.3 本地缓存二级加速对于极端热点的套餐数据可以引入Caffeine作为本地二级缓存Bean public CacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) { return new CaffeineRedisCacheManager( Caffeine.newBuilder() .expireAfterWrite(5, TimeUnit.MINUTES) .maximumSize(1000), RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofHours(1)) ); }4. 监控与问题排查4.1 缓存命中率监控通过自定义CacheInterceptor可以统计命中率public class MetricsCacheInterceptor extends CacheInterceptor { private final MeterRegistry meterRegistry; Override protected Object doGet(Cache cache, Object key, Method method) { Object value super.doGet(cache, key, method); String cacheName cache.getName(); meterRegistry.counter(cache.gets, cache, cacheName, hit, value ! null ? true : false).increment(); return value; } }4.2 常见问题排查表问题现象可能原因解决方案缓存未生效注解未正确应用或方法被内部调用确保方法为public且通过代理调用数据不一致缓存更新延迟或失败检查CachePut/CacheEvict逻辑Redis连接超时网络问题或连接池不足调整连接池参数增加超时设置内存占用高缓存无过期或缓存过多无用数据设置合理的TTL和淘汰策略4.3 缓存预热策略系统启动时自动加载热点数据EventListener(ApplicationReadyEvent.class) public void warmUpCache() { ListLong hotMealIds mealRepository.findTop100ByOrderBySalesDesc() .stream().map(Meal::getId).collect(Collectors.toList()); hotMealIds.parallelStream().forEach(id - { mealService.getMealById(id); }); }5. 性能对比与实战建议在实际的外卖系统中我们对套餐查询接口进行了压力测试测试环境4核8G服务器Redis 6.2集群1000个模拟套餐数据测试结果场景QPS平均响应时间数据库负载无缓存12085ms100%仅Redis350028ms5%Redis本地缓存580012ms2%实战建议对于套餐这类读多写少的数据TTL建议设置在30-60分钟关键业务操作如订单创建完成后立即刷新相关缓存使用CacheConfig在类级别统一配置公共缓存属性定期分析缓存命中率淘汰低效缓存在最近的一个外卖平台优化项目中这套方案将套餐查询的数据库访问量降低了82%API响应时间从平均76ms降至9ms。特别是在午晚高峰时段系统稳定性得到显著提升。