做点评类项目最让我上头的模块说实话不是登录也不是秒杀而是“达人探店”。登录和秒杀玩的是逻辑做对了就有成就感探店不一样它更像一个真实的内容产品要把图文列表做得好看要把点赞关注这些社交动作处理顺手还要在并发场景里把数据兜住一不小心就是缓存穿透加超发点赞。这篇笔记只聊第7个模块黑马点评里的达人探店从接口设计、缓存策略、前端联调到踩坑排查完整过一遍我的实现思路。如果你正在照着项目进度做这个模块或者你已经做完了一遍但总觉得代码只是“能跑”建议认真看我下面写的后半段尤其是点赞数据一致性、分页越界、缓存穿透这几块属于不做会发现不了、做了会翻天覆地的细节。1. 模块定位与技术方案选型1.1 先搞清楚探店模块到底在解决什么问题黑马点评这个项目本身是围绕“本地生活”做的核心场景是用户打开首页浏览附近的店、看看有什么优惠活动但单纯做商户列表就太硬了。达人探店这个模块的作用是把“商家铺位”升级成“内容流”让用户愿意在刷到一篇探店图文之后真的动身去店里。换句话说这是把用户留在平台、提升交易转化率的关键一环。所以探店模块的本质是“内容社交”而不是简单的一张列表页。它不只是把博客数据查出来渲染背后还牵扯到三个能力第一内容展示能力也就是热门探店笔记的推荐列表和个人主页的动态列表第二互动能力点赞、观看、关注第三发布能力用户能够上传图文形成新的内容供给。搞清楚这三层之后很多设计决策就顺了。比如列表接口为什么用分页为什么需要缓存热点数据为什么点赞要用 Redis 而不是直接改 MySQL为什么关注逻辑要单独建表。这些都不是面试八股而是这个业务场景逼着你必须考虑的问题。1.2 为什么技术栈最终选了这一套我见过的学习笔记里很多同学会在做这个模块时纠结一个问题要不要上 ES要不要用消息队列事实是学习项目最大的价值不是把某一块技术做到极致而是用最直接的方式解决当前场景下的痛点再留好扩展空间。我最终选择的技术栈是Spring Boot 做后端MySQL 存业务数据Redis 缓存热点和点赞状态前端用 Vue 系的小程序端框架实现页面。没有引入搜索中间件也没有搞复杂的消息链路理由很朴素达人探店列表虽然访问量大但数据量级在项目初期远达不到需要搜索引擎的规模一条 SQL 加缓存就能扛住点赞数这类高频写操作不适合直接打 MySQLRedis 的 Set 结构天然适合记录“谁点过赞”既能去重又能做互斥比单纯加一减一的计数器安全得多前端页面如果和微信小程序或者 uni-app 联动Vue 的组合式 API 会让你在调接口、维护页面状态时少写很多样板代码。这套组合还有一个隐藏优点容易排查。Redis 的 key 设计一旦出问题你直接用命令行 scan 一个前缀就能把所有脏数据捞出来不用祈祷日志有详细链路。对于做学习项目的人来说可观测性甚至比性能更重要。2. 后端数据模型与核心接口设计2.1 博客表结构设计的逻辑依据达人探店的内容主体是“博客”很多人第一反应就是把字段全堆在一张表里标题、内容、图片、点赞数、评论数、用户信息。我最初也这么干过后来发现这是个坑。正确的做法是把用户信息抽出去只存 user_id。因为用户表和博客表是两个完全不同维度的数据用户信息可能频繁变更比如昵称、头像如果把这些字段冗余到博客表里每次用户改头像就得同步改历史博客代价太大。表里存 user_id查询时再去用户表关联或者用内存缓存补全才是常规做法。我用的博客表结构大概是这样的CREATE TABLE tb_blog ( id bigint(20) NOT NULL COMMENT 主键, shop_id bigint(20) DEFAULT NULL COMMENT 关联商户id, user_id bigint(20) NOT NULL COMMENT 发布用户id, title varchar(255) NOT NULL COMMENT 探店标题, images varchar(2048) DEFAULT NULL COMMENT 图片列表逗号分隔或JSON, content varchar(2048) DEFAULT NULL COMMENT 探店正文, liked int(10) unsigned NOT NULL DEFAULT 0 COMMENT 点赞数, comments int(10) unsigned NOT NULL DEFAULT 0 COMMENT 评论数, create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个核心设计点我详细说一下第一个是images字段。它不适合做成单值因为探店笔记通常有多张图。方案有两种一种是把图片 ID 存成逗号分隔一种是存 JSON 数组的字符串。学习项目我用逗号分隔逻辑简单前端 split 一下就能渲染后续如果要做真正的富媒体内容再迁移也不难。第二个是点赞数的存储。我用了一个liked字段存冗余值但在高并发下不能直接拿它当唯一数据源。核心思路是Redis 里维护该博客的点赞用户 SetSet 的大小才代表真实点赞数MySQL 里的liked字段只当缓存展示和兜底初始化用。这样可以避免点赞、取消点赞都要直接 update 一条 MySQL 记录带来的锁竞争。第三个是主键类型。我直接用了 bigint而不是 int。看着不起眼但前端 JavaScript 在处理超过安全整数范围的数字时会出现精度丢失一旦主键用雪花算法生成你就可能遇到点赞记录窜到别人头上的诡异 bug。所以接口返回时所有大整数 ID 我都序列化成字符串这个放在后面常见问题里再展开。2.2 热门探店列表的分页与缓存实现探店列表最常用的入口是“推荐”动态用户一打开页面就要加载一批热门笔记。接口设计上我给它定了一个请求参数current表示页码固定每页 10 条RestController RequestMapping(/blog) public class BlogController { GetMapping(/hot) public Result queryHotBlog(RequestParam(value current) Integer current) { return blogService.queryHotBlog(current); } }Service 层实现不能只是简单分页还要把每个博客关联的用户信息、当前用户是否点赞都补全。public Result queryHotBlog(Integer current) { // 1. 分页查询当前页博客 PageBlog page blogService.lambdaQuery() .orderByDesc(Blog::getLiked) .page(new Page(current, 10)); // 2. 获取当前页记录 ListBlog records page.getRecords(); if (records null || records.isEmpty()) { return Result.ok(Collections.emptyList()); } // 3. 填充用户信息并检查是否点过赞 records.forEach(blog - { fillUserInfo(blog); isBlogLiked(blog); }); // 4. 返回结果 return Result.ok(records); }这里有两个细节容易被忽略。细节一是fillUserInfo。博客表里只有 user_id前端列表要显示用户头像和昵称我不能每条博客都去数据库查一次用户那会变成经典 N1 问题。我用了一个内存 Map 做去重批量加载遍历记录收集所有 user_id再用in语句一次性查出全部用户放 Map 里按 key 取用。实测下来10 条数据和一个用户查 10 次响应时间能从 200 毫秒降到 20 毫秒左右。细节二是isBlogLiked。这个方法的本质是判断“当前登录用户是否已经点赞过这条博客”很多直接把点赞按钮做成纯前端的东西忽视了这一点——用户刷新页面后会看到点赞按钮状态和点赞数又对不上了。正确做法是在查询列表时就把它一并查出来private void isBlogLiked(Blog blog) { UserDTO user UserHolder.getUser(); if (user null) { // 未登录一律视为未点赞 blog.setIsLike(false); return; } String key RedisConstants.BLOG_LIKED_KEY blog.getId(); Boolean isMember stringRedisTemplate.opsForSet().isMember(key, user.getId().toString()); blog.setIsLike(Boolean.TRUE.equals(isMember)); }用 Set 判断会员简直是为这个场景量身定做的接口操作底层是 O(1)10 条列表只要 10 次 Redis 命令性能没有任何问题。2.3 缓存穿透、缓存击穿与缓存一致性怎么权衡做了缓存之后紧接着就要面对缓存穿透问题。热门博客列表如果被频繁刷接口每次请求都打到 MySQL数据库早晚要崩。我见过最直接的处理方式就是把列表结果缓存进 Rediskey 设计成cache:hot:blog:{page}过期时间设 30 分钟。但是只做缓存还不够。一个高频访问页面如果某个 key 失效瞬间所有查询会拥到数据库这就是缓存击穿。所以我用了 Redis 空值缓存来防穿透并且缓存重建时加了互斥锁public Result queryHotBlogWithCache(Integer current) { String key RedisConstants.CACHE_HOT_BLOG current; String cachedJson stringRedisTemplate.opsForValue().get(key); if (StringUtils.isNotBlank(cachedJson)) { ListBlog list JSON.parseArray(cachedJson, Blog.class); return Result.ok(list); } // 缓存未命中加锁重建 String lockKey RedisConstants.LOCK_HOT_BLOG current; Boolean locked stringRedisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (Boolean.TRUE.equals(locked)) { try { // 二次检查防止上一个线程已经重建完成 cachedJson stringRedisTemplate.opsForValue().get(key); if (StringUtils.isNotBlank(cachedJson)) { return Result.ok(JSON.parseArray(cachedJson, Blog.class)); } PageBlog page blogService.query() .orderByDesc(liked) .page(new Page(current, 10)); ListBlog records page.getRecords(); records.forEach(this::fillUserInfo); stringRedisTemplate.opsForValue().set(key, JSON.toJSONString(records), Duration.ofMinutes(30)); return Result.ok(records); } finally { stringRedisTemplate.delete(lockKey); } } // 没有拿到锁就返回空等待下一个请求重建 return Result.ok(Collections.emptyList()); }这里要说明一下加锁重建代码里的互斥锁只在高并发场景下才会真正起作用平时单机测试你根本感知不到它。很多同学写完这段代码觉得“多此一举”其实是没理解缓存失效瞬间的请求风暴。学习项目里我建议保留因为这就是面试题库里“缓存击穿”对应的落地方案。缓存一致性上我的策略很简单列表缓存设置一个合理 TTL不追求强一致点赞数变更时不主动删除列表缓存只更新 Redis 里的 Set当 TTL 到期后列表自然刷新。为什么这么做因为博客列表本来就是偏展示性数据用户看到点赞数延迟几秒钟完全无感知但如果你为了强一致去主动删缓存反而会把简单问题搞复杂还可能因为缓存重建失败造成长时间没有列表数据。2.4 点赞与点赞排行榜的实现细节点赞功能是达人探店模块里互动体验的关键。设计上说点赞有两个需求一是“谁点过这个赞”用来做去重二是“按点赞时间排序”用来做点赞排行榜。基于这两个需求Set 只满足第一个得用 ZSet。我把 key 设计为blog:liked:{blogId}用 ZSet 存储member 是用户 idscore 是用户点赞的时间戳既能判断是否已经点过赞又能按时间取最近点赞的用户public Result likeBlog(Long blogId) { Long userId UserHolder.getUser().getId(); String key RedisConstants.BLOG_LIKED_KEY blogId; Double score stringRedisTemplate.opsForZSet().score(key, userId.toString()); if (score null) { // 未点赞加入 ZSetscore 是当前时间戳 stringRedisTemplate.opsForZSet().add(key, userId.toString(), System.currentTimeMillis()); // 数据库点赞数 1这里用 incr 而不是读取旧值再写回 boolean isSuccess updateBlogLiked(blogId, true); if (!isSuccess) { // 博客不存在或更新异常回滚 Redis 操作 stringRedisTemplate.opsForZSet().remove(key, userId.toString()); return Result.fail(点赞失败); } } else { // 已点赞取消点赞 stringRedisTemplate.opsForZSet().remove(key, userId.toString()); updateBlogLiked(blogId, false); } return Result.ok(); }这里特别强调一个“执行顺序”问题先操作 Redis 还是先操作 MySQL如果先操作 MySQL 成功但 Redis 失败就等于 MySQL 记了 1但用户刷新后看到自己没点过赞如果先操作 Redis 成功但 MySQL 失败点赞数就虚高。真正的方案是先操作 Redis再更新 MySQL如果 MySQL 失败就把 Redis 回滚。虽然做不到原子性但至少把最坏情况控制为“Redis 有脏数据MySQL 兜底”后面通过定时任务或数据比对可以纠正。另外点赞排行榜接口也直接用 ZSet 的reverseRange拿最近点赞的 Top 用户列表不用再单独建表代码量少很多。3. 前端页面实现与联动调试3.1 列表页渲染的要点后端接口设计完了前端页面才是用户能感知到的部分。达人探店的首页建议用信息流卡片每张卡片包含作者头像、昵称、发布时间、探店标题、图片区、点赞按钮和评论入口。前端拿到接口数据后有一个极其常见的坑后端返回的id和userId是 Long 类型如果没做字符串序列化在小程序里很容易失去精度。我给出的解决办法是在后端配置里统一对 Long 类型进行 Jackson 序列化时转 StringConfiguration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(Long.TYPE, ToStringSerializer.instance); }; } }这样前端不管拿 id 还是 userId 都不会出现“明明是这个用户的点赞结果记到别人头上”的低级错误。列表页还需要处理下拉刷新和上拉加载。下拉刷新时重新请求第一页上拉加载时页码加一。加载到最后一页之后要有一个“没有更多数据”的兜底提示避免用户反复请求空数据。很多同学在做分页时只看到了返回结果却忘掉了返回结果里的hasNext字段导致无限请求最后一页这是很辣眼睛的操作。3.2 发布探店笔记的完整流程达人探店的核心场景不只是看还要能发。发布笔记的流程分四步填写标题和正文、选择图片、上传图片、提交 blog 数据。图片上传这块有个经验想分享不要把图片服务器搭在项目进程里也别把文件塞进数据库。学习项目里最常见做法是上传到对象存储服务后端提供一个上传接口返回图片 URL前端把 URL 拼进博客的 images 字段再提交。这样 DB 和文件存储分离的好处是以后迁移服务器不用把图片数据和业务数据一起迁备份也方便。上传接口的简单实现PostMapping(/upload) public Result uploadImage(MultipartFile file) { if (file null || file.isEmpty()) { return Result.fail(文件不能为空); } try { // 校验文件类型和大小图片不超过 2MB if (file.getSize() 2 * 1024 * 1024) { return Result.fail(图片大小不能超过2MB); } String originalFilename file.getOriginalFilename(); String suffix originalFilename ! null ? originalFilename.substring(originalFilename.lastIndexOf(.)) : .jpg; // 生成不重复文件名这里可以用 uuid 时间戳 String objectName /blog/ System.currentTimeMillis() _ UUID.randomUUID() suffix; // 上传至对象存储省略具体云厂商 SDK 调用 String url uploadFile(objectName, file.getInputStream()); return Result.ok(url); } catch (IOException e) { return Result.fail(上传失败); } }发布博客的接口相对简单核心是校验登录状态记录 user_id然后插入数据库。但这里我建议前端先展示本地预览再异步提交这样用户感知是即时发布体验比一直转圈好很多。发布成功之后再清掉列表缓存下次进首页就是最新的笔记。3.3 详情页与点赞交互的细节详情页是用户停留时间最长的地方除了博客全文还要展示作者关注按钮和点赞列表。这里最容易出 bug 的是“关注状态”。如果只有发布人详情信息时前端总拿达人 id 判断自己是否关注了对方但后端只返回了关注数没有返回 Boolean 类型的是否关注字段首页就显示成“关注”按钮即使你已关注也还是“关注”非常离谱。所以我实现了一个接口专门返回用户是否已关注目标作者GetMapping(/{id}/isFollow) public Result isFollow(PathVariable(id) Long authorId) { Long userId UserHolder.getUser().getId(); Follow follow followService.lambdaQuery() .eq(Follow::getUserId, userId) .eq(Follow::getFollowUserId, authorId) .one(); return Result.ok(follow ! null); }还有点赞交互的“乐观 UI”问题。前端用户点击点赞按钮立刻把按钮颜色变红、点赞数加 1然后异步请求后端。如果后端返回失败再回滚 UI。这种交互比等后端返回再变色流畅太多但前提是前端需要记录一个本地状态不能让后端返回的数据覆盖掉用户的即时操作。4. 常见问题与排查技巧实录4.1 点赞数对不上的排查思路做点赞功能最容易出现的一个问题Redis 里记录用户点过赞但 MySQL 的点赞数没变或者反过来用户取消点赞后 Redis Set 里没了MySQL 的计数却还是原来那个数。我排查这类问题有个固定顺序首先查 Redis 里 ZSet 的成员和 MySQL 里的 liked 字段是否一致然后看 Service 里是否做了回滚最后看是不是并发导致两个用户同时点赞数据库更新时用了旧值覆盖新值。比如点赞数更新我建议用update t_blog set liked liked 1 where id ?而不是先select liked再update。后者在高并发下一定丢数据前者至少能保证单条记录的自增是原子的。4.2 列表缓存出现脏数据怎么处理列表缓存是所有 Redis 问题里最难排查的一种因为你不知道缓存里到底存的什么版本的数据。我在测试时遇到过“点赞数显示 1但点进去详情页点赞数是 0”的灵异事件最后定位是 cache 里存的是旧的 Blog 对象里面liked字段还是 0详情页实时查了 Redis 的 ZSet所以不一样。处理方案是不要懒列表返回给前端之前把 Blog 里的点赞数从 Redis ZSet 实时读出并塞进去private void fillLikeCountFromRedis(Blog blog) { String key RedisConstants.BLOG_LIKED_KEY blog.getId(); Long count stringRedisTemplate.opsForZSet().zCard(key); if (count ! null) { blog.setLiked(count.intValue()); } }这段代码可以在 list 和 detail 两个接口里复用保证展示数据一致性。4.3 分页越界和最后一页重复请求分页越界这个问题很隐蔽。用户快速滑到页面底部前端一次性发多个请求后端某一次 current 超过了实际总页数本来应该返回空列表但因为接口里没做空值判断直接返回 null 给前端前端对 null 调用.length就报错页面直接白屏。后端要做的第一件事是判断 records 是否为空第二件是返回一个明确的hasNext标记。前端要做的配合是当 hasNext 为 false 时就不要再发请求了直接显示“已经到底啦”。这块前后端要约定好而不是各搞各的。4.4 图片防盗链与跨域问题做图片上传功能的第二天我发现本地能访问图片但真机上图片裂了。第一反应是跨域问题排查之后发现是防盗链对象存储的容器默认不允许外部站点直接引用。解决办法有两个一个是在对象存储配置里设置允许的空 Referer另一个是给图片服务域名做代理让请求带上合法 Referer。学习项目里我建议用第一个配置简单本地测试不折腾。5. 个人实操心得这个模块做完我最大的感受是“内容型功能比纯业务型功能更考验前后端协同”。登录、优惠券这些功能后端接口给对了前端基本就是傻渲染达人探店不一样它涉及图片、点赞、关注、分页、缓存、并发任何一个环节没想清楚用户看到的页面都是别扭的。我建议做这个模块时不要急着直接照着项目代码敲一遍。先自己画一遍信息架构页面上有哪些元素每个元素的数据来自哪里哪些数据是高频变化的哪些数据可以缓存把这几个问题想明白你写出来的代码会自动比原项目更合理。最后再分享一个小技巧开发时可以在 Redis 里故意把某条热门博客的缓存 TTL 设成 1 秒然后用压测工具模拟几十个并发请求来观察缓存击穿和缓存穿透的处理逻辑配合日志查看锁竞争次数。这一招对理解缓存比光看文档有用得多。有这个耐心后面做到秒杀、优惠券模块的时候你的并发处理思路会清晰不少。