Redis缓存店铺查询：读多写少场景下的设计与实践

店铺项目做到第二天，终于轮到性能优化里最经典也最实用的一环：把店铺查询信息加进Redis缓存。“黑马店铺”这个项目本身就是读多写少的典型——用户进首页看店铺列表、点店铺详情、搜索店铺，几乎全是查询操作。如果每次查询都直接打到MySQL，并发稍微上来一点，数据库连接池就会被打满，接口的响应时间也会肉眼可见地变差。这天的实操核心就一句话：在店铺查询接口里接入Redis，让热门店铺的查询直接命中缓存，数据库只负责兜底。

这篇文章我会直接把当天做的设计、代码、验证过程以及后来踩过的坑都写出来。适合正在做电商、店铺、商品这类读多写少业务的后端开发，也适合刚学完Spring Boot和Redis基础、想看看真实业务里缓存怎么落地的同学。整个改造不复杂，但你如果能理解每一步为什么这么做，后面自己写缓存逻辑就不会再稀里糊涂了。

1. 店铺查询缓存的设计思路：为什么选Redis而不是别的

1.1 读多写少的业务模型决定了缓存方案

店铺数据有几个特点：变化频率低、查询频率高、单条数据量小。用户打开App看到的一家店铺，它的名称、评分、营业时间、地址这些信息可能在一天之内都不会变，但同一个店铺详情页一天会被成千上万人反复打开。这种情况就是教科书里说的“读多写少”，也是缓存最擅长解决的场景。

MySQL单机在普通配置下大概能扛到每秒几千次查询，听起来不少，但一旦遇到秒杀、活动页、热点店铺集中曝光，一个详情接口的QPS就可能冲到几万。数据库连接的创建和销毁、磁盘IO、SQL解析，这些开销在高峰期都会被无限放大。Redis就不同，数据在内存里，单线程模型配合IO多路复用，单机读QPS可以到十万以上，而且响应时间稳定在毫秒级。用个生活化的类比：MySQL是水库，Redis是每家每户楼顶的水塔，用户用水先取水塔里的存量，水塔空了再去水库抽水，水库的压力自然就小了。

但缓存不是万能的。它解决的是“高频读”的问题，不是“海量存储”的问题。店铺总数可能上百万条，不可能全塞进Redis；也没必要。我们只缓存那些真正会被反复查的店铺，其他冷门店铺走数据库就行。所以设计缓存的第一步不是写代码，而是想清楚要缓存哪些数据、用什么维度组织、数据失效了怎么办。

1.2 Key和Value怎么设计：从Redis数据类型说起

Redis有String、Hash、List、Set、ZSet等数据类型，店铺查询这种场景，大多数人第一反应是String存JSON，也有人觉得Hash更省内存。这两种我都试过，这里直接说结论：单体业务里，用String存JSON是最省心、最通用的方案。

Key的格式一定要设计清楚。我习惯用“业务模块前缀:业务ID”的结构，比如店铺详情就用cache:shop:1，其中1就是店铺的ID。这么做的好处有几个：一是所有店铺缓存都在同一个命名空间下，不会跟其他业务混在一起；二是在可视化工具里一眼就能看到这个key属于哪个业务；三是后面做批量删除、按前缀扫描、清理缓存都很方便。最忌讳的是直接拿id当key，比如1、2，到时候跟其他模块的缓存撞了都不知道怎么回事。

Value选择上，我做了个简单的对比：

店铺详情是一个完整的对象，查询时整条返回，很少需要只改某个字段。用String存JSON，反序列化直接得到对象，逻辑最简单。后面要加字段、嵌套对象、改结构，JSON都不会让你头疼。

1.3 Cache Aside模式：读缓存、回填、删除的闭环

店铺查询用的缓存模式，业界叫Cache Aside，也叫旁路缓存。套路非常固定：

• 读请求：先查Redis，命中就直接返回；没命中就去查MySQL，查到后把结果写入Redis并设置过期时间，再返回给前端。
• 写请求：先更新MySQL，然后删除Redis里对应的缓存，而不是去更新缓存。

为什么写的时候是“删缓存”而不是“更新缓存”？举个我实际遇到的例子。假设店铺的评分从4.5改到了4.8，我更新完数据库之后，顺手把Redis里的店铺JSON也改成4.8。看着没问题，但并发场景下会有个大坑：线程A更新数据库为4.8，线程B读到旧值4.5，B比A更晚把4.5写进Redis，然后A再更新缓存为4.8，覆盖了B的操作，最终缓存里是对的；但如果顺序反过来，A先更新缓存4.8，B后写4.5，那缓存里就成了旧值，而且这个旧值可能要在TTL过期后才会被纠正。删除缓存就不一样了，我不碰旧值，只删掉它，下次读请求自然会把最新值从数据库回填到缓存里。这是一种“惰性”思维，也是我后来做各种缓存方案时最常用的一条准则：拿不准的时候，优先删，不要改。

这一天的业务操作里，读链路是核心：店铺查询先走缓存，未命中再回源数据库，然后把查询结果回填到Redis。理解了这个闭环，后面看代码就会觉得每一步都顺理成章。

2. 缓存落地前的准备工作：环境、依赖与序列化选型

2.1 Redis安装与Spring Boot依赖配置

动手写代码之前，先确认Redis本身是可用的。我自己在Windows上开发时，直接下载Windows版Redis压缩包，解压后双击redis-server.exe就能跑起来，默认端口6379。macOS用户用Homebrew装：brew install redis，然后brew services start redis。Linux服务器上也可以用包管理器装，比如Ubuntu的apt install redis-server。需要说明的是，Windows版的Redis一般是Redis Labs维护的社区移植版，生产环境还是建议用Linux；但本地开发调试完全够用。

项目里接入Redis很简单，Spring Boot项目加上一个starter即可：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

我遇到过一个版本坑：Spring Boot 2.x用的是spring.redis.*配置项，Spring Boot 3.x改成了spring.data.redis.*。网上很多教程还是老写法，照抄到新项目里会发现配置根本不起作用。当前项目用的配置长这样：

spring: data: redis: host: 127.0.0.1 port: 6379 database: 0 lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0 timeout: 5s

database这个参数值得多说一句。Redis默认有16个逻辑库，编号0到15。我习惯把业务数据放0库，临时数据或锁放1库，测试数据放2库。不是说必须这样分，但环境多了之后，分开能省很多排查问题的时间。实际上很多公司会用不同端口甚至不同实例来隔离，本地开发用database分词也够用。Lettuce是Spring Boot默认的Redis客户端，池化参数按默认就能用，不用刻意调。如果追求极致性能再研究连接池，平时手动调整反而容易把并发调崩。

2.2 序列化方案怎么选：StringRedisTemplate与JSON

这是新手最容易踩坑的地方。默认注入的RedisTemplate使用的序列化器是JdkSerializationRedisSerializer，它会把对象序列化成以\xAC\xED开头的二进制字节。直接用默认配置存一条数据，再用可视化工具打开Redis，看到的是一堆乱码，根本不知道里面存的是什么，而且占用的空间也比原始数据大好几倍。

我在项目里更习惯用StringRedisTemplate。它内部使用String序列化，只会把字符串原样存进去。存储的时候我把店铺对象手动转成JSON字符串，读取的时候再把JSON字符串反序列化成对象。这样存进Redis里的数据是明文JSON，在Redis Desktop Manager这类可视化工具里直接能看到内容，哪怕线上出了问题，用redis-cli查也一目了然，排查效率不知道高了多少。

序列化时用Jackson的ObjectMapper就行，Spring Boot自带的。我封装了一个简单的写法：

private static final ObjectMapper MAPPER = new ObjectMapper(); private Shop toShop(String json) { try { return MAPPER.readValue(json, Shop.class); } catch (JsonProcessingException e) { throw new RuntimeException("店铺JSON反序列化失败", e); } } private String toJson(Shop shop) { try { return MAPPER.writeValueAsString(shop); } catch (JsonProcessingException e) { throw new RuntimeException("店铺对象序列化失败", e); } }

如果用自定义RedisTemplate，也可以设置GenericJackson2JsonRedisSerializer，让它自动序列化对象，但这样JSON里会多一个@class字段用来存储类的全限定名。好处是可以自动反序列化，坏处是类重命名或移动包之后旧缓存会全部反序列化失败，而且数据可读性变差。所以我个人始终推荐String + 手动JSON，简单直接，可控性最强。

2.3 TTL设计：缓存过期时间不是随便填的

说到回填缓存，一定要带上过期时间。很多新手写缓存时不设置TTL，结果缓存里存了一条跟数据库永远不一致的数据，直到手动删缓存或者重启才恢复。我见过生产事故就是这种原因造成的——运营改了价，用户端三天没刷新，投诉都堆成山了。

TTL给多少，要看业务容忍度。店铺基础信息变化不频繁，给30分钟到1小时都合理；如果运营经常改活动信息，就缩短到5到10分钟。黑马店铺这个场景，我给的是30分钟。但还有一个要注意的点：所有店铺的缓存如果定在整点或同一时刻过期，很可能造成缓存雪崩——大量key同时失效，一瞬间所有请求都穿透到MySQL。解决办法很简单，过期时间加一个随机偏移量：

long ttl = 30 * 60 + new Random().nextInt(300); // 30分钟加0到5分钟的随机值

这招成本极低，但效果非常明显。后来我做的所有缓存设计，基本都会遵守“TTL必须是基础值+随机扰动”这条规则。

3. 店铺查询信息写入Redis的完整实现

3.1 Service层改造：查询店铺先查缓存

这里是当天实操的核心代码。原来的查询逻辑很简单，直接调getById查数据库，现在要改成查询时先走Redis。我用的类名是ShopServiceImpl，继承MyBatis Plus的ServiceImpl，目标是重写店铺查询方法，把Redis缓存合并进查询链路。

@Service public class ShopServiceImpl extends ServiceImpl<ShopMapper, Shop> implements IShopService { @Autowired private StringRedisTemplate stringRedisTemplate; private static final String CACHE_SHOP_KEY = "cache:shop:"; private static final ObjectMapper MAPPER = new ObjectMapper(); @Override public Shop queryShopById(Long id) { // 1. 拼接Redis Key String key = CACHE_SHOP_KEY + id; // 2. 优先查询Redis缓存 String shopJson = stringRedisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(shopJson)) { Shop shop = toShop(shopJson); log.debug("店铺查询命中缓存, id = {}", id); return shop; } // 3. 缓存未命中，查询MySQL数据库 Shop shop = getById(id); if (shop == null) { // 数据库也没查到，返回空 return null; } // 4. 数据库查询结果回填Redis，设置过期时间 String json = toJson(shop); stringRedisTemplate.opsForValue().set(key, json, Duration.ofMinutes(30)); // 5. 返回查询结果 return shop; } }

步骤很容易理解：先查Redis，命中就返回；没命中才查数据库；查到之后顺手把结果写进Redis，下次同样的查询直接命中。这里的核心是最后那个set(key, json, Duration.ofMinutes(30))，它把店铺查询信息真正地“添加”到了Redis里，这一步缺了，整个缓存链路就不闭环。

写这段代码时有几个细节我特别提醒一下。一是StrUtil.isNotBlank判断空字符串，因为后面做缓存穿透时我会往Redis里存空字符串，空字符串不能算命中但也不能再去查库，这是个边界情况。二是反序列化失败时不要直接吞异常，要抛出来，否则缓存里存的是脏数据，接口返回的也是null，排查问题会非常痛苦。三是日志里把“命中缓存”和“走数据库”区分开，本地调试时一眼就能看出缓存到底生效没有。

3.2 Controller与调用链：一次请求怎么走通

Controller倒是没太多变化，保持轻量：

@RestController @RequestMapping("/shop") public class ShopController { @Autowired private IShopService shopService; @GetMapping("/{id}") public Result queryShopById(@PathVariable("id") Long id) { Shop shop = shopService.queryShopById(id); return Result.ok(shop); } }

重点在于理解一次请求走通的路径。用户请求/shop/1，进入Controller，调用Service的queryShopById(1)。第一次请求时，Redis里没有cache:shop:1这个key，查询逻辑落到MySQL，getById(1)从数据库捞出店铺数据，序列化成JSON写入Redis，TTL设置为30分钟，然后把数据返回给前端。前端拿到数据渲染页面。第二次用户再请求同样的接口，Redis里已经有了cache:shop:1，直接反序列化返回，MySQL全程不参与。

从调用方的感受来说，第一次请求可能耗时30毫秒，第二次开始就是2到3毫秒。这个差别在单次请求里不算夸张，但放大到每天上百万次查询，数据库减少的负载就是数量级的差距。我实操时会在Service里分别打印“查缓存耗时”和“查数据库耗时”，对比结果非常直观，数据库查询普遍在20毫秒以上，缓存查询基本在1毫秒以内。

3.3 用可视化工具验证缓存是否生效

代码写完不能光看控制台日志，我习惯用可视化客户端确认缓存里的真实数据。macOS上我用的是Another Redis Desktop Manager，Windows上Redis Desktop Manager也很常见，这俩都是免费的图形化Redis客户端。

操作路径是：打开客户端，新建连接，填host为127.0.0.1、端口为6379，如果设过密码就在auth里填密码，点连接。连接成功后默认进到database 0，左侧会列出所有key。我刷新几遍页面之后，在key列表里能看到一条名为cache:shop:1的记录，双击打开value，里面是店铺对象的JSON字符串，包含店铺名、评分、地址这些字段，右下角还能看到剩余TTL在倒计时。这说明缓存回填成功了。

我每次做完缓存功能，都会用客户端手动做三个验证动作：一是在没访问过接口前确认key不存在；二是访问接口后确认key创建出来了，内容正确，TTL符合预期；三是在客户端里手动删掉这个key，再访问接口，确认数据库查询日志重新出现，说明缓存重建逻辑可靠。这套验证流程能覆盖大部分缓存读写问题，养成习惯之后，线上出问题也能少很多被动。

4. 缓存上线后踩过的坑：穿透、击穿、雪崩与一致性

4.1 缓存穿透：不存在的店铺ID也会打爆数据库

刚把缓存加上线，我就发现一个新问题：如果有人恶意或者不小心请求了一个不存在的店铺ID，比如/shop/999999，Redis里没有这个key，数据库里也没有这条店铺，每次请求都会穿透Redis直接打到MySQL。如果这种请求量再大一点，Redis在缓存层面就完全失去了拦截作用，数据库一样会被打爆。这就是缓存穿透。

解决思路很朴素：把查不到的“空结果”也缓存起来。我在查询到null的时候，往Redis里写一个空字符串，并且把过期时间设置得很短，比如5分钟。下次再查这个不存在的ID，Redis命中的是空字符串，直接返回null，数据库完全不用参与。代码就是在shop == null分支里补一行：

if (shop == null) { stringRedisTemplate.opsForValue().set(key, "", Duration.ofMinutes(5)); return null; }

这里有个细节：上面查询缓存时用的是StrUtil.isNotBlank(shopJson)而不是StringUtils.isNotEmpty，就是因为空字符串也是有效缓存，不能当作未命中。如果你用isNotEmpty判断，空字符串会被当成不存在，还是会穿透到数据库。

更高级的方案是布隆过滤器，把所有存在的店铺ID都预先加载到布隆过滤器里，查询前先判断ID是否存在，不存在直接返回。但这个方案有实现成本、有误判率，店铺这种数据量在百万级以下的时候，空值缓存完全够用。我个人的建议是：先做空值缓存，扛不住再说布隆过滤器，别一开始就上复杂方案。

4.2 缓存击穿与雪崩：热点Key的几种死法

缓存击穿和缓存雪崩经常被混在一起说，其实是两个问题。

缓存击穿针对的是单个热点Key。比如一家头部店铺的详情页，缓存Key是cache:shop:888，平时几万QPS全靠Redis扛。结果某一个瞬间这个Key的TTL刚好到期了，数据在Redis里被删除，下一个瞬间大量请求同时进来，发现缓存没命中，全部冲到MySQL。MySQL瞬间被打满，这就是击穿。本质上就是“某个Key过期时正好赶上超大流量”。

解决击穿最常用的是互斥锁，也叫Setnx锁。查询时没命中缓存，先尝试获取一把锁，获取成功才去查数据库；获取失败的请求说明有人正在重建缓存，可以让它短暂等待后重试查缓存。代码大致长这样：

// 尝试获取互斥锁，key为 lock:shop:888，超时10秒 Boolean locked = stringRedisTemplate.opsForValue() .setIfAbsent("lock:shop:" + id, "1", Duration.ofSeconds(10)); if (Boolean.TRUE.equals(locked)) { try { // 查数据库、回填缓存 } finally { // 释放锁 stringRedisTemplate.delete("lock:shop:" + id); } } else { // 休眠50毫秒后重查缓存 Thread.sleep(50); return queryShopById(id); }

缓存雪崩则是大量Key在同一时间过期。前面提到每个店铺过期时间都设置成30分钟，如果这些店铺是同一天同一批创建并首次被查询的，那它们的过期时间就会整齐地落在同一个时间点，导致大量Key同时失效，数据库瞬时承受巨大压力。解决办法我在2.3里已经说过了，给TTL加随机偏移量，让过期时间错开。这两件事一个靠锁，一个靠随机，原理都很简单，但缺一个都可能在生产环境翻车。

4.3 店铺信息更新后：先改库还是先删缓存

跟缓存相关的另一大类问题是数据一致性，说白了就是数据库里的店铺信息和缓存里的店铺信息对不上。黑马店铺项目里有修改店铺信息的接口，改动之后缓存必须同步处理。

业界标准做法是“先更新数据库，再删除缓存”。按这个顺序处理后，即使在更新数据库之后、删除缓存之前的窗口里出现读请求，最多也就是读到一次旧缓存，影响范围极小。反过来，如果先删缓存再更新数据库，问题就大了：线程A删掉缓存，线程B马上来读，发现缓存为空就查数据库，查到的是旧数据并写回缓存，然后线程A才把数据库更新成新值。最终缓存里存了旧数据，而且大概率要等TTL过期才能恢复，这就是我在1.3里提到的坑。

我在这天项目里顺手写了一个删除缓存的更新逻辑：

@Override public boolean updateShop(Shop shop) { // 1. 先更新数据库 boolean updated = super.updateById(shop); // 2. 再删缓存 if (updated) { stringRedisTemplate.delete(CACHE_SHOP_KEY + shop.getId()); } return updated; }

删除缓存这个操作失败怎么办？代码层面通常是先更库、后删缓存，但删缓存也可能因为网络异常失败。为了尽可能保证最终一致，可以在删除失败时做重试，或者配合延迟双删——就是删除缓存后等待几百毫秒再删一次。延迟双删能规避并发窗口里旧数据回填的问题。不过黑马店铺这个项目的数据一致性容忍度没那么高，先更库再删缓存已经足够。真追求极端一致性，就得引入消息队列或者Binlog订阅来做缓存最终一致性了，那是后话。

4.4 排障利器：几个看缓存现场的小技巧

缓存类问题最难的不是写代码，而是线上出了状况时怎么快速定位。这里分享几个我常用的排查动作。

第一，用redis-cli直接查Key。redis-cli进入命令行后，TTL cache:shop:1可以看剩余过期时间，GET cache:shop:1可以看缓存的原始值，EXISTS cache:shop:1判断Key是否存在。如果发现缓存里存的JSON跟数据库不一致，基本可以断定是更新链路出了问题。

第二，用MONITOR命令看实时读写。这个命令会打印Redis接收到的所有命令，本地调试或者压测时能很清楚地看到请求到底是不是从缓存命中的。但它很消耗性能，生产环境千万不能长时间开。

第三，给缓存Key加业务前缀的最大好处是可以用SCAN命令做模糊匹配。比如我想清理所有店铺缓存，SCAN 0 MATCH cache:shop:* COUNT 1000就能分批扫出所有店铺Key，再批量删除。注意不能用KEYS cache:shop:*，生产环境数据量大时KEYS会阻塞Redis。

第四，Redis Desktop Manager这类可视化工具不只是用来“看”数据的。它支持直接在界面上删Key、改TTL、执行命令。每次上线前我都会用它把相关缓存清一遍，避免开发环境的历史缓存干扰测试结果。团队协作时，这个操作习惯能省掉很多“我改了代码怎么没生效”的沟通成本。

另外还有一个小窍门：上线前最好把Java对象字段修改跟缓存格式联动检查一遍。如果Shop类加了新字段，旧缓存反序列化时Jackson默认不会报错，但新字段会读不到；如果删了字段，旧缓存里多余字段也会被忽略。这些都还好，最怕的是把字段类型改了，比如从int改成String，旧缓存反序列化可能会直接抛异常。遇到这种情况，提前清一下对应缓存，或者做一个版本号前缀，比如cache:shop:v2:1，能更从容地完成升级。

做缓存这个功能，你会发现前期写代码很快，真正花时间的都是这些边界情况和排障手段。黑马店铺二刷到第二天，我最大的收获不是我写出了那段查缓存的代码，而是把“缓存命中率”“TTL设计”“删除缓存策略”这些概念真正落到了实际业务里。这套思路后面还能继续扩展，比如店铺列表页用Redis存List、店铺搜索热词用ZSet、详情页用逻辑过期方案来解决热点数据缓存重建问题。每一条路都是从这个最简单的“单店铺查询写Redis”开始长出来的。

最后再分享一个个人体会：别急着给所有数据都上缓存。缓存是给高频、只读、可容忍短暂不一致的数据准备的，如果一条数据一天都查不了几次，或者修改极其频繁，加缓存反而增加复杂度和出问题概率。先把业务模型想清楚，再去动Redis，才是正确的顺序。