Redis缓存优化实战：外卖平台性能提升方案

1. 项目背景与核心价值

最近在开发一个外卖平台的缓存优化项目，主要解决高峰期菜品和套餐信息查询的性能瓶颈问题。当用户量激增时，频繁访问数据库会导致响应延迟，直接影响用户体验。通过引入Redis缓存机制，我们成功将热门菜品的查询响应时间从平均200ms降低到20ms以内。

这个方案特别适合中小型外卖平台的技术团队参考，尤其是那些正在经历业务增长但技术架构还没跟上的项目。我在实施过程中踩过不少坑，今天就把完整的实现思路和实操细节分享给大家。

2. 技术方案设计

2.1 整体架构设计

我们采用经典的"缓存旁路"模式（Cache-Aside Pattern），主要处理两种业务场景：

1. 菜品/套餐信息缓存
2. 用户购物车数据缓存

对于菜品这类基础数据，采用被动缓存策略。当查询请求到达时：

1. 先检查Redis缓存
2. 命中则直接返回
3. 未命中则查询MySQL并写入缓存

购物车数据则采用主动缓存策略，因为：

• 用户操作频繁（添加/删除）
• 数据实时性要求高
• 每个用户的数据独立

2.2 Redis数据结构选型

经过性能测试对比，最终选择以下数据结构：

• 菜品/套餐信息：Hash类型

  • 优势：天然适合对象存储，支持字段级操作
  • Key设计：dish:{dishId}

• 购物车数据：Hash类型

  • Key设计：cart:{userId}
  • Field：菜品ID
  • Value：菜品数量+规格信息（JSON格式）

注意：不要使用String类型存储整个对象JSON，虽然实现简单但无法支持字段级更新，会导致缓存频繁失效。

2.3 缓存更新策略

针对不同业务场景，采用混合更新策略：

3. 核心代码实现

3.1 菜品缓存实现

java复制// 获取菜品详情（带缓存）
public DishVO getDishWithCache(Long dishId) {
    String redisKey = "dish:" + dishId;
    
    // 1. 先查缓存
    Map<Object, Object> dishMap = redisTemplate.opsForHash().entries(redisKey);
    if (!dishMap.isEmpty()) {
        return BeanUtil.mapToBean(dishMap, DishVO.class, false);
    }
    
    // 2. 缓存未命中，查数据