当前位置：首页 > news >正文

Redis 缓存策略：借助缓存优化数据库性能并保障数据一致性

news 2025/6/6 6:56:33

一、缓存加载策略：按需加载与数据库兜底

1. 缓存 Key 设计

// 以业务类型+分类ID构建唯一Key（示例：菜品分类ID）
String redisKey = "dish_" + categoryId;

设计原则：
- 采用 业务类型_关联ID 格式（如 dish_1 表示分类 ID 为 1 的菜品缓存）
- 避免使用模糊 Key（如 dish_*）导致缓存穿透，精确命中目标数据

2. 缓存查询逻辑

// 优先从Redis获取数据
List<DishVO> cacheData = (List<DishVO>) redisTemplate.opsForValue().get(redisKey);
if (cacheData != null && !cacheData.isEmpty()) {return Result.success(cacheData); // 命中缓存，直接返回
}

核心优势：
- 减少数据库查询压力，提升响应速度（Redis 内存读写速度约为 MySQL 的 1000 倍）
- 适用于读多写少场景（如菜品查询、字典数据）

3. 数据库兜底机制

// 缓存未命中时，从数据库查询并加载到缓存
Dish dish = new Dish();
dish.setCategoryId(categoryId);
dish.setStatus(StatusConstant.ENABLE); // 仅查询起售菜品
List<DishVO> dbData = dishService.listWithFlavor(dish);
redisTemplate.opsForValue().set(redisKey, dbData, 30, TimeUnit.MINUTES); // 设置缓存过期时间

完整代码

//构造redis的KEYString RedisKey="dish_"+categoryId;//查询redis内是否有数据List<DishVO> list= (List<DishVO>) redisTemplate.opsForValue().get(RedisKey);//缓存中有数据 直接返回即可if(list!=null && list.size()>0){return Result.success(list);}/*** 当数据库中发生变化时，就要清理缓存，避免缓存与数据库中的数据不一致* 当数据库中发生新增、修改、删除、起售，停售的操作时，就要清理缓存*///redis没有数据 从数据库中查询后，加载到redis内Dish dish = new Dish();dish.setCategoryId(categoryId);dish.setStatus(StatusConstant.ENABLE);//查询起售中的菜品list = dishService.listWithFlavor(dish);//加载到缓存内（redis）redisTemplate.opsForValue().set(RedisKey,list);return Result.success(list);

二、缓存一致性维护：数据变更时主动清理缓存

1. 新增数据场景

@PostMapping
public Result addDish(@RequestBody DishDTO dishDTO) {dishService.addDish(dishDTO);// 新增数据后，删除对应分类的缓存String key = "dish_" + dishDTO.getCategoryId();redisTemplate.delete(key);return Result.success();
}

逻辑说明：
新增菜品属于分类数据变更，删除对应分类的缓存（如 dish_1），下次查询时自动重新加载最新数据

2. 修改数据场景

@PutMapping
public Result modifDish(@RequestBody DishDTO dishDTO) {dishService.modifDish(dishDTO);// 修改数据后，删除关联分类的缓存（支持跨分类场景优化）DeleteDishReids(RedisConstant.ALLDISH_); // 临时方案：先全量清理（待优化为精准删除）return Result.success();
}

当前局限与优化方向：
- 现状：直接删除所有菜品缓存（dish_*），适用于简单场景
- 优化：若修改涉及分类变更，需同时删除原分类和新分类的缓存（如 dish_oldCategoryId 和 dish_newCategoryId）

3. 状态变更场景（启售 / 停售）

@PostMapping("status/{status}")
public Result dishHalt(@PathVariable Integer status, Long id) {dishService.updatedish(status, id);// 状态变更影响数据有效性，删除所有菜品缓存DeleteDishReids(RedisConstant.ALLDISH_);return Result.success();
}

业务逻辑：
菜品状态（如停售）变更后，所有相关缓存数据需失效，确保前端获取到最新可用菜品列表

4. 批量删除场景

@DeleteMapping
public Result deleDish(@RequestParam List<Long> ids) {dishService.deleteDish(ids);// 批量删除时无法精准定位分类，临时全量清理缓存DeleteDishReids(RedisConstant.ALLDISH_);// 优化方向：统计删除菜品的分类ID，精准删除对应缓存（如通过SQL查询分类ID列表）return Result.success();
}

优化思路：
通过数据库查询批量删除菜品的分类 ID 集合，避免全量清理：

// 伪代码：从数据库获取删除菜品的分类ID列表
List<Long> categoryIds = dishMapper.getCategoriesByDishIds(ids);
categoryIds.forEach(categoryId -> redisTemplate.delete("dish_" + categoryId));

三、缓存清理工具方法：批量删除与 Key 模式匹配

private void DeleteDishReids(String keyPrefix) {// 使用Redis Key模式匹配（如 dish_*）获取所有相关KeySet<String> keys = redisTemplate.keys(keyPrefix + "*");if (!keys.isEmpty()) {redisTemplate.delete(keys); // 批量删除，减少Redis交互次数}
}

技术要点：
- 使用 redisTemplate.keys("prefix*") 按前缀模糊匹配 Key
- 批量删除（delete(Set)）比单个删除更高效，减少网络 IO 消耗

四、缓存策略总结与优化方向

1. 当前策略优势

读写分离：读请求优先走缓存，写请求更新数据库后清理缓存，适用于高并发读场景
简单可靠：基于同步清理策略（写操作后立即删缓存），避免异步延迟导致的不一致

场景	现有方案缺陷	优化方向
跨分类修改	全量清理缓存	解析修改后的分类 ID，精准删除对应缓存（需业务层传递新旧分类 ID）
批量删除	无法定位具体分类	通过数据库查询删除菜品的分类 ID 列表，实现精准删除
缓存穿透	未处理无效 Key 请求	添加布隆过滤器（Bloom Filter），提前拦截无效 Key 的查询
缓存雪崩	无过期时间错峰机制	为不同 Key 设置随机过期时间（如 30~60 分钟），避免集中失效