伙伴匹配系统实战复盘：标签匹配、缓存穿透与并发控制

很多人把“伙伴匹配系统”当作一个普通的全栈练手项目，但我想说的是，这个项目如果真能把它嚼透了，完全可以成为你简历里最硬核的一个亮点。为什么这么说？因为一个看似“年轻人组队玩”的功能，背后几乎把后端开发最常遇到的工程问题都串了一遍：用户体系、标签匹配、组队场景下的并发控制、缓存穿透、分布式登录、定时任务清理，甚至连推荐算法都能给你整个简单版本进去。我最近完整复习了这个项目，从功能列表到核心源码再到面试追问，整个过了一遍，踩过不少坑，也理清了很多之前没想明白的细节。这篇文章就把我的复习笔记整理出来，尽量说人话，不堆术语，适合正在做这个项目的人、准备面试的人，以及想通过一个完整案例把后端知识串起来的朋友。

好，不废话了，直接进入正题，我先从整体设计思路开始拆。

1. 项目整体设计与技术选型复盘

1.1 这个项目到底在解决什么问题

伙伴匹配系统的核心诉求很简单：用户注册登录后，可以创建自己的标签（比如“篮球”、“夜跑”、“二次元”、“考研党”），也可以给自己打上一堆个性化标签，然后系统根据这些标签去匹配其他兴趣相近的用户，让用户可以组队、结伴、一起做某件事。

但“简单”只是表面。如果你只把它当成一个CRUD项目来写，那确实没什么好复习的。真正有价值的点在于：匹配这个动作背后的数据结构和算法选择、组队这个动作背后的并发和事务控制、以及整个系统在用户量增长后可能出现的性能瓶颈。

所以复习这个项目的时候，我给自己定的主线是三条：

• 用户与标签数据模型怎么设计，才能既灵活又高效地支撑匹配？
• 匹配算法怎么选，才能兼顾准确率、性能、以及代码可解释性？
• 核心业务操作（组队、加入队伍）怎么保证不出并发问题？

这三条主线，其实就是这个项目在简历上和面试中最大的价值所在。

1.2 技术栈选型和为什么这么选

这个项目最常见的技术栈组合是：Spring Boot + MyBatis-Plus + MySQL + Redis + Vue 3 + Vant UI。我之前还见过有人用Spring Cloud Alibaba做微服务版的，但对一个“伙伴匹配”业务来说，微服务纯属过度设计，单机单体把性能优化做到位，反而是更合理的方案。

逐个说一下选型的理由：

很多人选型只看“流行”，不太关注“为什么”。我说一下我的理解：MyBatis-Plus 真正强的地方是单表操作极其顺手，比如按ID查用户、按标签模糊查用户列表，这些高频操作用它的 LambdaQueryWrapper 几行代码就搞定，不需要写一大堆XML。而Redis在这个项目里承担的职责比想象中重要得多，后面我单独开一节细说。

1.3 项目目录结构与模块划分

复习项目的时候我习惯把代码目录重新过一遍，因为目录结构本身就是一种“设计文档”。伙伴匹配系统的典型目录我梳理成下面这样：

text复制src/main/java/com/example/partner
├── common         # 通用返回体、错误码、异常处理
├── config         # 全局配置（跨域、JSON序列化、MyBatis-Plus分页插件）
├── controller     # 接口层
├── service        # 业务逻辑层
├── mapper         # 数据访问层
├── model          # 实体类、DTO、VO
├── utils          # 工具类（算法、正则、JWT等）

这个分层比较常规，重点在 service 层。我见过不少人把业务逻辑全部堆在 Controller 里，接口看着功能是好的，但一旦涉及事务、异常回滚、多条数据操作，就会非常痛苦。所以复习的时候可以特别关注一件事：凡是涉及“多步写操作”的服务方法，有没有加 @Transactional 注解？如果没有，那队伍创建成功后成员表写入失败怎么办？

2. 核心功能拆解：从用户注册到标签匹配

2.1 用户注册登录与分布式会话

用户模块是几乎所有系统的入口，伙伴匹配系统也不例外。注册登录这里最值得复习的不是简单的用户名密码存库，而是登录态的存储方案。

我最初做的版本是把登录用户信息直接放到Session里，单机部署没有任何问题，但后来为了后续扩展，改成了Redis存储登录态，用户登录成功后生成一个随机token，把token作为key、用户信息序列化后作为value存进Redis，并设置过期时间，然后把token写回前端。前端后续请求都在Header里带上token，后端通过拦截器统一解析。

用Redis替换Session的核心原因是：如果以后想把服务水平扩展成多实例部署，Session默认存在单台服务器内存里，负载均衡一转发，登录态就丢了。Redis是独立存储，所有实例都可以访问，天然解决这个问题。

这里有个细节要特别注意——用户信息存Redis时要考虑序列化方式。我试过默认的JDK序列化，Redis里存出来是一堆乱码，虽然不影响功能，但排查问题的时候非常痛苦。后来改成Jackson序列化，可读性好很多，而且跨语言通用。配置方式是用RedisTemplate的时候自定义序列化器，网上有很多现成配置，直接抄下来理解一下即可。

2.2 用户标签的数据模型设计

标签是这个系统的灵魂，数据模型设计好不好，直接影响匹配算法的可实现性。

常见的设计方案有两种：

1. 逗号分隔字符串：用户表加一个字段 tags，存“篮球,夜跑,二次元”，简单粗暴，但查询、更新、统计都很难做。
2. 用户-标签关联表：用户表、标签表、用户标签关系表，规范但查询麻烦，标签多了性能压力也不小。
3. 用户表设计JSON字符串字段 + 程序内解析：用户表用一个字段存JSON数组，比如["篮球", "夜跑"]，匹配时查出列表在内存里比对。

伙伴匹配系统最常用的方案是第三种，因为它的标签数量是有限的（比如由管理员预置或用户从候选列表中选择），用JSON字段存完全够用，而且逻辑简单、查询速度快。你可以想象一下：如果用关联表，查询一个用户的标签要联表查三次，而用JSON字段，一次SQL就能把用户数据和标签一起查出来。

但需要提前想清楚的一个问题是：如果未来标签数量上升到百万级，很多用户都有相同的“篮球”标签，用JSON字段查“所有打过篮球标签的用户”就得全表扫描了。这个问题的解法一般是引入倒排索引的思路，单独维护标签和用户ID列表的映射关系，类似搜索引擎，但实际做的时候成本不低，权衡下来，项目阶段用JSON字段是最高效的方案。

2.3 匹配算法到底在匹配什么

这部分是整个项目最核心的点之一，我必须单独拿出来仔细说。先明确匹配的输入和输出：

• 输入：当前登录用户的标签列表（比如 ["篮球", "夜跑", "编程"]）
• 输出：按照匹配度从高到低排列的其他用户列表

看到这个需求，第一反应就是：怎么定义两个用户之间的相似度？

最简单可实现的方案是余弦相似度或者Jaccard相似度。Jaccard 相似度的公式是两个集合交集大小除以并集大小，非常适合标签这种集合型数据。比如用户A的标签是{"篮球", "夜跑"}，用户B的标签是{"篮球", "游泳"}，那么交集是{"篮球"}，并集是{"篮球", "夜跑", "游泳"}，相似度就是 1/3 ≈ 0.33。

另一种方案是编辑距离（Levenshtein Distance），在《程序员鱼皮》那套经典课程里用的是这个算法，我当时学的时候也是一头雾水，后来想明白了：它其实就是把一个字符串转换成另一个字符串所需的最少编辑操作次数（插入、删除、替换）。对标签来说，把每个人的标签列表拼接成字符串，然后算两个字符串的编辑距离，距离越小表示越相似。

我当时做的时候采用的是“标签加权评分 + 编辑距离兜底”的方式，思路大概是：

1. 先算出当前用户和目标用户的共同标签数量。
2. 把共同标签多的排在前面。
3. 如果共同标签数量相同，再用编辑距离做二次排序。

这个方案的好处是逻辑简单、面试时好解释，而且对用户的直觉来说，共同标签多的人当然更匹配，这个排序规则是能被用户直接感知到的。

2.4 编辑距离算法的代码实现与优化

编辑距离的经典实现是动态规划，两层循环构建一个 (m+1) × (n+1) 的矩阵。我直接把核心代码写出来：

java复制public static int editDistance(String word1, String word2) {
    int m = word1.length();
    int n = word2.length();
    int[][] dp = new int[m + 1][n + 1];
    for (int i = 0; i <= m; i++) {
        dp[i][0] = i;
    }
    for (int j = 0; j <= n; j++) {
        dp[0][j] = j;
    }
    for (int i = 1; i <= m; i++) {
        for (int j = 1; j <= n; j++) {
            if (word1.charAt(i - 1) == word2.charAt(j - 1)) {
                dp[i][j] = dp[i - 1][j - 1];
            } else {
                dp[i][j] = Math.min(dp[i - 1][j - 1], 
                        Math.min(dp[i - 1][j], dp[i][j - 1])) + 1;
            }
        }
    }
    return dp[m][n];
}

如果你第一次接触这个算法，不用慌，理解它的时候可以这么想：dp[i][j] 表示 word1 前 i 个字符转换成 word2 前 j 个字符需要的最少操作次数。当新字符相等的时候，不需要额外操作；不相等的时候，可以从三种操作里挑一个代价最小的：替换（dp[i-1][j-1]+1）、删除（dp[i-1][j]+1）、插入（dp[i][j-1]+1）。

不过说实话，这个算法的时间复杂度是 O(m×n)，如果把所有用户都两两算一遍编辑距离，用户量超过几千就会出现明显的性能问题。所以我在实际实现中做了一个简单的优化：先通过共同标签数量过滤掉完全没交集的用户，只对共同标签数量大于等于1的用户计算编辑距离，大部分不相关的用户根本不会进入算法计算环节，这样性能会好很多。

3. 匹配搜索与缓存穿透问题

3.1 基于标签的搜索流程

匹配功能的前端调用逻辑通常是：用户进入匹配页，系统拉取与自己相似度最高的用户列表。后端接口大致流程是这样的：

1. 从当前登录用户信息中获取标签列表。
2. 查询所有启用的用户，过滤掉自己。
3. 逐一计算和当前用户的相似度，按降序排列。
4. 返回Top N个用户给前端展示。

步骤2是最容易写出慢SQL的地方。如果用 MyBatis-Plus 的 like 查询，SQL大概是：

sql复制SELECT * FROM user WHERE tags LIKE '%篮球%' OR tags LIKE '%夜跑%'

这在小数据量下没问题，但它是全表扫描，一旦用户量上来就会很慢。我当时在测试环境只放了300个用户，没感觉，后来模拟了2万条数据，这个查询一下子要几百毫秒，整个接口响应时间就上去了。

优化思路有两个方向：

• 维护标签倒排索引：在内存里维护一个 Map<String, List>，key是标签名，value是用户ID列表，查询时直接拿到候选用户，再精确计算相似度。这在单机应用里足够好用，也是我在项目里最终采用的方式。
• 数据库全文索引：MySQL的全文索引或者ES，适合更复杂的搜索场景，但这个项目用不上，引入ES反而增加部署和维护成本。

3.2 Redis缓存：哪些该存、哪些不该存

复习这个项目时，Redis缓存的使用是一个高频问题。我总结下来，伙伴匹配系统里Redis值得缓存的数据有三类：

1. 用户登录态：key为token，value为用户信息，有过期时间。
2. 热门用户列表：比如首页推荐的TopN用户，可以缓存5分钟。
3. 标签候选列表：管理员配置的标签集合基本不变，可以从缓存里读。

有一个很容易被忽略的坑：缓存“用户列表”时，如果用户信息更新了，缓存里的旧数据怎么处理？我当时直接把缓存删掉，等下次请求再回源数据库加载，也就是俗称的“Cache Aside Pattern”，简单可靠。如果你选择了更新缓存而不是删缓存，就会面临缓存和数据库数据不一致的难题，处理起来很麻烦，收益却不高，不推荐。

3.3 缓存穿透与布隆过滤器

“缓存穿透”是这个项目面试中几乎必问的一个点。简单解释一下：如果用ID查询一个不存在的用户，缓存里没有，数据库里也没有，每次请求都会直接打到数据库，如果被恶意刷接口，数据库压力会非常大。

布隆过滤器是应对缓存穿透的经典方案。它的原理是用一个很长的二进制位数组和多个哈希函数，判断一个元素“一定不存在”或者“可能存在”。用大白话说：它会把所有用户ID先映射到位数组里，查询时先用布隆过滤器判断一下这个ID是不是真的存在，如果过滤器说“不存在”，直接返回，根本不会去查数据库。

我当时为了写这个点专门找了Guava的BloomFilter工具类实现，其实代码量很少。但复习的时候我发现很多人对布隆过滤器有个误解：它判断“可能存在”是有一定误判率的，误判会导致少数无效ID还是查了数据库，所以布隆过滤器通常只能把穿透概率降低到极低水平，并不能完全杜绝。真正的兜底方案还是在数据库层面，比如查询空结果时也把null值缓存很短的时间。

4. 组队功能的并发控制与数据一致性

4.1 组队业务流程和数据表设计

伙伴匹配系统的第二个核心功能是组队，用户创建一个队伍，其他用户可以申请加入。这里涉及的实体有：用户、队伍、用户队伍关系。

队伍表的关键字段包括：队伍名称、描述、最大人数、过期时间、创建人ID、队伍状态（公开/私有/加密）。用户队伍关系表包括：用户ID、队伍ID、加入时间、是否队长。

这里有一个容易被忽略的设计细节：为什么要把“是否队长”放在关系表里，而不是在队伍表里存一个队长ID？我的理解是：关系表能更自然地表达“用户和队伍的从属关系”，而且查“某用户加入了哪些队伍”和“某队伍有哪些成员”都能用这一张表完成。如果单独在队伍表里存队长ID，查起来语义有点混乱，一般不太会在项目阶段这么设计。

4.2 加入队伍时最常见的并发问题

我当时调试“加入队伍”功能时遇到过两个典型的并发问题：

1. 超员问题：队伍最多5人，第6个和第7个用户同时发起加入请求，两个请求都先查到当前队伍人数4人，于是都判断可以加入，最后队伍变成6个人。
2. 重复加入问题：同一用户疯狂快速点击“加入队伍”按钮，结果在关系表里插入了多条记录。

这两个问题的本质都是并发下先查后写导致的竞态条件。解决方法通常有三种：

• 数据库唯一约束：对用户队伍关系表的(用户ID, 队伍ID)加唯一索引，这样重复加入直接报错，简单粗暴有效。
• 乐观锁：队伍表加一个version字段，更新人数时检查version是否变化，变化则重试或报错。
• 分布式锁：用Redis的setnx命令加锁，保证同一时刻只有一个请求在处理同一个队伍的加入逻辑。

我在项目里最终的方案是：唯一索引兜底 + 代码里用SELECT ... FOR UPDATE锁定队伍行，然后再判断人数。SQL大致长这样：

sql复制SELECT * FROM team WHERE id = ? FOR UPDATE

这个SQL会把队伍行锁住，其他事务修改同一行时会阻塞等待，相当于在数据库层面做了串行化。虽然并发性能会下降一些，但对这个项目来说完全够用，而且逻辑最容易理解。

4.3 事务边界与异常回滚

组队功能涉及两个写操作：往队伍表插入记录、往关系表插入记录。这两个操作必须放在同一个事务里——队伍创建成功但关系插入失败的话，整个操作都应该回滚，否则就会出现“有人创建了队伍但队伍里没有队长”的脏数据。

Java里用@Transactional注解可以很容易地搞定事务，但有两点需要注意：

• 事务不生效的经典场景：同一个类内部方法调用时，@Transactional不会生效。原因是Spring的事务代理机制，内部调用走的是this对象而不是代理对象。我当时就踩过这个坑，写了一个createTeamAndJoin方法，没通过注入的方式调用，结果事务完全没有回滚。
• 异常一定要抛出RuntimeException：如果方法内部自己catch住了异常，事务不会感知到，也就不会回滚。所以事务方法里要么不catch，要么catch之后throw new RuntimeException(e)。

4.4 定时任务清理过期队伍

队伍有有效期，比如创建后7天内可以加入，超时就关闭。这个需求最简单可靠的方案是：每次查询队伍时判断过期时间并过滤，同时启动一个定时任务，定期把已经过期的队伍状态更新为“已解散”。

定时任务用的Spring的@Scheduled注解，配合cron表达式控制频率。我当时设置的策略是项目里所有匹配接口在查询时都会主动过滤过期队伍，定时任务作为兜底，每30分钟把状态批量更新掉。这样即使定时任务挂了，用户也不会看到已经过期的队伍。

5. 面试向复盘：高频追问与答题逻辑

5.1 项目难点该怎么说

每次面试官问“你这个项目的难点是什么”，最怕听到的回答是“登录模块用了JWT”、“列表用了分页”。这些话说出来等于告诉面试官你没有真正思考过项目。

伙伴匹配系统里，我会建议你用下面三个方向去组织回答：

• 算法选型上的权衡：为什么标签匹配用编辑距离/Jaccard，而不是用数据库的like查询？可以从准确性和性能两个角度去讲。
• 并发控制上的取舍：队伍加入的并发问题用了什么方案？为什么不用分布式锁？可以从项目规模、实现复杂度、维护成本三个维度去说。
• 数据一致性上的设计：JSON字段存标签的利弊、缓存和数据库的一致性怎么保证？这些点能体现你对数据模型的理解。

面试官最反感的是背概念，最喜欢的是有对比、有代价分析的回答。比如你说“我用了Redis缓存热门用户列表”，一定要接着说“但是缓存会导致数据不一致，我的容忍度是5分钟，所以设置了比较短的过期时间，并且更新资料时主动删除缓存”，这样才有深度。

5.2 面试官追问频率TOP 5

我梳理了几个面试官大概率会追问的问题，每个我都附上回答思路：

5.3 从“能做出来”到“能讲清楚”

做项目最怕的就是“代码写完了，但讲不清楚为什么这样写”。复习这个项目，我觉得最有效的办法是画流程图，不是用画图工具画那种精美的图，而是自己在纸上把一次完整请求的调用链画出来。

画完之后问自己几个问题：

• 用户点“匹配”按钮之后，前端请求到哪个接口？
• 这个接口从Redis还是从数据库取数据？
• 标签匹配是发生在内存还是SQL里？
• 如果用户不存在，哪一层会拦截？

你能闭着眼把这条链路完整讲出来，面试官问任何细节基本都接得住。我当时复习就是这个笨方法，一遍一遍画，画到不用看笔记也能讲出来为止。

写在最后

这个项目到今天已经有非常多的教程和现成代码了，但我觉得“做出来”和“讲清楚”之间差距非常大。复习伙伴匹配系统，最重要的不是记住每个功能的代码，而是理解每个技术选型背后的原因和代价。我对这个项目最大的感受是，它真的能把你在课堂上学到的零散知识——事务、索引、缓存、算法、并发——全部拧成一股绳。如果你也正在复习这个项目，建议你不要急着刷下一个新项目，先把这里面的匹配算法和组队并发这两块彻底吃透，这两块吃透了，面试的时候这个项目的含金量才会真正释放出来。另外，有条件的话，可以把数据库灌个几万条测试数据，亲眼看一看慢SQL出现前后接口耗时的变化，这种感觉比看十篇教程都来得深刻。