做跳蚤市场的商品推荐系统最头疼的不是Spring Boot怎么写而是“协同过滤算法怎么落地”。我接手这个项目的时候也踩了不少坑——从算法选型到数据表设计从相似度计算到冷启动处理每一步都有讲究。这篇项目总结就围绕“springboot 协同过滤算法 跳蚤市场商品推荐”这条主线把我在实际开发中的设计思路、核心代码、踩坑记录和优化经验完整分享出来希望给正在做同类系统尤其是毕设或者个人项目的朋友一个可直接参考的模板。1. 项目整体设计与算法选型解析1.1 跳蚤市场场景下的推荐需求拆解跳蚤市场和常规电商平台最大的区别在于商品是个人卖家发布的闲置物品品类杂、数量少、生命周期短而且大部分商品没有销量数据。这种情况下做推荐系统如果直接照搬淘宝那种基于用户行为的复杂推荐架构肯定行不通。先拆一下业务需求。跳蚤市场里用户的核心行为就三类浏览商品、收藏商品、发布商品。而推荐系统的目标很直白——在用户打开首页时给他推送“可能感兴趣”的闲置商品提高浏览深度和成交概率。推荐策略上我选了协同过滤算法作为核心引擎原因有三个跳蚤市场的商品没有统一的属性标准比如成色、价格区间浮动大基于内容的推荐需要大量人工标注特征工程成本太高。协同过滤不关心商品“是什么”只看用户和商品的交互行为矩阵天然适合这种缺乏结构化特征的场景。跳蚤市场用户基数不大一般校内或社区级别协同过滤的计算量完全可控不需要上重型的分布式计算框架。具体算法路径上我采用的是“基于物品的协同过滤ItemCF为主基于用户的协同过滤UserCF为辅”的双通道策略。为什么主用ItemCF因为跳蚤市场的用户兴趣变化快今天想买书架明天可能想看键盘ItemCF能根据“当前浏览了某商品”立刻推荐相似商品实时性好而UserCF更适合发现新兴趣但计算代价大、实时性差适合做离线兜底推荐。1.2 技术栈选型与版本确认这个项目的技术底座就是标题里的Spring Boot。选Spring Boot而不是Spring MVC或SSH核心原因是它能把“配置地狱”变成“自动装配”尤其在整合MyBatis、Redis这些组件时依赖管理和配置项都省心很多。我用的版本组合如下已实测跑通组件版本说明JDK1.8稳定兼容性好不推荐JDK 17踩坑Spring Boot2.7.x2.x系列最成熟的末班车3.x坑多且部分依赖不兼容MyBatis-Plus3.5.x单表操作零SQL推荐模块需要写复杂SQL时才用原生Redis5.x/6.x缓存推荐结果降低算法重复计算的压MySQL5.7/8.0存储用户、商品、行为、推荐结果四类数据Maven3.6项目构建和依赖管理有一个很实际的提醒Spring Boot版本不要盲目追新。我一开始试过Spring Boot 3.2 JDK 21结果MyBatis-Plus的旧版本和Jakarta命名空间冲突折腾了一整天。后来退回2.7.x所有依赖一键解决。做项目稳定性永远比新特性重要。1.3 为什么协同过滤在Spring Boot中适合离线计算 缓存回源在Spring Boot里集成协同过滤算法有一个很关键的设计决策算法计算不可能在每次用户刷新页面时实时跑一遍。原因很简单假设商品数量是1万用户是1万构建评分矩阵就要做亿级别的运算如果在请求线程里同步执行接口响应时间直接爆炸。所以整体架构上我采用了“离线计算、缓存回源”的模式定时任务Spring Scheduled每次固定时间去计算协同过滤推荐结果写入Redis。用户请求推荐接口时先从Redis取缓存结果如果缓存命中就直接返回。Redis里没有数据时降级方案是查MySQL里最近一次计算的推荐结果表或者干脆返回热门商品列表保证接口不报错。这套设计把“算法耗时”和“接口响应快”这两个矛盾拆开了算法多慢都无所谓反正后台算用户感知不到接口只查缓存响应时间稳定在几十毫秒以内。完整架构流程可以理解成用户行为日志 - MySQL行为表 - 离线定时任务读取 - 构建评分矩阵 - 计算相似度 - 生成TopN推荐 - 写入Redis - 用户请求 - 读取Redis缓存 - 返回推荐结果这个流程中Spring Boot扮演的是“连接器”的角色定时调度、数据读写、缓存管理、接口暴露全部由它承担协同过滤算法则作为核心引擎以Service层组件的形式嵌入到业务逻辑里。2. 核心算法原理与实现步骤2.1 评分矩阵的构建行为权重怎么设协同过滤算法第一步是把用户行为转化成“用户-商品”评分矩阵。跳蚤市场不像电商有明确的星级评分所以我需要把隐式反馈换算成分数。这里分享我用的权重规则实测效果还算合理用户行为行为描述评分权重浏览点击商品详情页停留超过5秒1分收藏点击收藏按钮表示强意向2分发布用户自己发布了相似品类的商品1.5分购买/求购交易成功或发起求购3分需要说明的是浏览行为的判定不能只看“点没点”要配合停留时长。我做过测试如果只要点击就给分首页推荐位会被那些“只看图不点详情”的无效浏览刷爆推荐质量明显下降。所以数据采集时前端需要上报停留时长后端过滤掉停留小于5秒的浏览记录。评分矩阵的结构是稀疏矩阵用户数×商品数绝大多数格子都是空的。处理这种稀疏矩阵Java里最省内存的方式是用MapLong, MapLong, Double嵌套结构外层key是userId内层key是itemIdvalue是评分值。这样只存储有效交互数据不会因为矩阵过大撑爆内存。2.2 相似度计算余弦相似度的选择与实现基于物品的协同过滤核心是计算商品之间的相似度。相似度公式有很多种——余弦相似度、皮尔逊相关系数、Jaccard相似度我最终选了余弦相似度。原因是它在处理稀疏数据时表现稳定而且实现简单计算效率高。余弦相似度的计算逻辑把每个商品看成一个向量向量维度是所有用户向量的值是用户对该商品的评分。两个商品向量的夹角越小说明喜欢这两个商品的用户群体越重合商品就越相似。公式记作cos(θ) (A · B) / (|A| × |B|)其中A · B是两向量的点积|A|是向量A的模长。具体的Java实现我放在了更后面的代码章节。计算时有个很关键的小技巧在计算相似度之前要做“反向索引”优化。如果直接双重遍历所有商品算相似度1万个商品就要算近5000万对性能完全扛不住。常规做法是先筛选出“有共同评分用户”的商品对只算这些有交集的组合。我计算时发现加了这层筛选后相似度计算时间从十几分钟降到了几十秒效果立竿见影。2.3 推荐候选集生成与TopN排序有了商品之间的相似度矩阵给用户推荐就很简单了原理就是一句话找到用户最近交互过的商品找出和这些商品最相似的其它商品排除掉用户已经买过或看过的商品按综合分数排序取前N个。推荐分数的计算方式我采用的是累加模式预测用户u对商品i的评分 Σ(用户u对商品j的行为评分 × 商品i与商品j的相似度)其中商品j是用户u最近有过正反馈行为的商品集合商品i是候选商品。经过这次累加后每个候选商品都会得到一个综合推荐分降序排列取前N个就是最终的推荐列表。这里还有一个业务规则要处理跳蚤市场每个用户自己发布的商品不应该出现在自己的推荐列表里。另外被下架、已售出的商品也要在推荐前过滤掉。这些规则我放在RecommendFilter组件里统一处理避免每个接口都重复写过滤逻辑。3. Spring Boot工程搭建与数据库设计3.1 Maven项目结构与依赖配置项目结构遵循Spring Boot规范的分层架构Maven依赖主要集中在pom.xml里。这里给出核心依赖配置parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies !-- Web 核心 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus 持久层 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency !-- Redis 缓存 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency !-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency !-- Lombok简化实体类 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies项目结构上我这里用了比较标准的代码分层src/main/java/com/example/fleamarket ├── controller # REST接口层 │ ├── RecommendController.java │ ├── ProductController.java │ └── UserController.java ├── service # 业务逻辑层 │ ├── recommend │ │ ├── ItemCFRecommender.java # 协同过滤核心算法 │ │ ├── RecommendCacheService.java │ │ └── RecommendScheduleTask.java │ ├── product │ └── user ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库实体类 ├── config # 配置类Redis、MyBatis等 └── common # 通用工具与返回结果封装这样的划分逻辑很明确controller只负责参数接收和结果返回service专注业务规则推荐算法单独放一个包隔离起来方便后续替换算法策略而不影响其它模块。3.2 数据库核心表设计用户、商品、行为表数据库设计是整个推荐系统的地基表结构一旦定死后期返工成本极高。我设计了5张核心表下面给出每张表的用途和关键字段。用户表t_user和普通电商用户表没有本质区别重点字段是user_id、nickname、avatar、create_time。跳蚤市场可以加一个credit_score信用分字段方便做用户信用分层但这和推荐算法本身关系不大不展开。商品表t_product是推荐系统最核心的数据来源之一关键字段设计如下CREATE TABLE t_product ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 商品ID, title varchar(128) NOT NULL COMMENT 商品标题, description text COMMENT 商品描述, category_id bigint(20) DEFAULT NULL COMMENT 商品分类ID, price decimal(10,2) DEFAULT NULL COMMENT 价格元, original_price decimal(10,2) DEFAULT NULL COMMENT 原价, seller_id bigint(20) NOT NULL COMMENT 发布者ID, status tinyint(4) DEFAULT 1 COMMENT 状态1上架 0下架 2已售出, cover_image varchar(255) DEFAULT NULL COMMENT 封面图URL, view_count int(11) DEFAULT 0 COMMENT 浏览次数, favorite_count int(11) DEFAULT 0 COMMENT 收藏次数, create_time datetime DEFAULT NULL COMMENT 发布时间, PRIMARY KEY (id), KEY idx_seller_id (seller_id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;给category_id和seller_id建索引非常重要。推荐算法在过滤和筛选时经常按这两个字段做查询没有索引的话在商品数据量过万后SQL性能会明显下降。用户行为表t_user_action是推荐系统的“燃料”协同过滤算法的数据源就是它CREATE TABLE t_user_action ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, product_id bigint(20) NOT NULL COMMENT 商品ID, action_type tinyint(4) NOT NULL COMMENT 行为类型1浏览 2收藏 3发布 4购买/求购, action_score double DEFAULT 1 COMMENT 行为评分权重, create_time datetime DEFAULT NULL COMMENT 行为时间, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_product_id (product_id), KEY idx_user_product (user_id, product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户行为表;联合索引idx_user_product是推荐系统最常用的查询路径——“查某个用户的所有行为”“查某个商品被哪些用户行为过”这两种查询都会命中这个索引务必加上。另外行为数据只增不改非常适合定时批量处理所以这张表没有设计更新时间字段。另外还需要一个推荐结果表t_recommend_result存储离线计算的推荐结果用于缓存未命中时的兜底查询。以及一个定时任务执行记录表t_recommend_task_log用来记录每次推荐计算的开始时间、耗时、生成结果数量。3.3 定时任务框架搭建离线计算的调度入口协同过滤是离线计算的定时任务用Spring Boot自带的Scheduled就能搞定。推荐计算的触发策略我设置为每10分钟执行一次原因很实在跳蚤市场的用户活跃高峰和商品新增速度都比较快如果每小时算一次用户看到的新商品推荐可能会滞后如果每1分钟算一次商品向量还没来得及更新计算意义不大也浪费资源。定时任务代码骨架如下Component Slf4j public class RecommendScheduleTask { Resource private ItemCFRecommender itemCFRecommender; Resource private RecommendCacheService cacheService; // 每10分钟执行一次推荐计算 Scheduled(cron 0 */10 * * * ?) public void runRecommend() { long startTime System.currentTimeMillis(); log.info(推荐计算任务开始, time{}, startTime); try { // 1. 加载用户行为数据 ListUserAction actions loadUserActions(); // 2. 执行协同过滤核心计算生成每个用户的TopN推荐 MapLong, ListLong recommendMap itemCFRecommender.recommendForAllUsers(actions); // 3. 将推荐结果写入Redis和MySQL cacheService.saveRecommendResult(recommendMap); } catch (Exception e) { log.error(推荐计算失败, e); } long costTime System.currentTimeMillis() - startTime; log.info(推荐计算任务结束, 耗时{}ms, costTime); } }有一点经验要说明Scheduled默认是单线程串行执行的如果有多个定时任务都要跑建议在配置类里显式声明一个线程池避免多个任务排队互相阻塞。我是这样配置的Configuration public class ScheduleConfig implements SchedulingConfigurer { Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setScheduler(Executors.newScheduledThreadPool(5)); } }4. 协同过滤算法核心代码实现4.1 余弦相似度计算的Java实现算法核心代码是整个项目的灵魂我特意把它独立成工具类保证业务代码和算法代码解耦。先看余弦相似度的实现Component public class CosineSimilarity { /** * 计算两个商品向量的余弦相似度 * * param vector1 商品1的评分向量key为userIdvalue为评分 * param vector2 商品2的评分向量key为userIdvalue为评分 * return 相似度值范围[-1, 1]越大越相似 */ public double calculate(MapLong, Double vector1, MapLong, Double vector2) { // 分子点积 double dotProduct 0.0; // 分母两个向量的模长乘积 double norm1 0.0; double norm2 0.0; // 遍历向量1的每个维度同时在向量2中查找共同维度 for (Map.EntryLong, Double entry : vector1.entrySet()) { Long userId entry.getKey(); double score1 entry.getValue(); norm1 score1 * score1; Double score2 vector2.get(userId); if (score2 ! null) { dotProduct score1 * score2; } } // 计算向量2的模长 for (Double score : vector2.values()) { norm2 score * score; } if (norm1 0.0 || norm2 0.0) { return 0.0; } return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); } }计算实现中要注意的是遍历只在外层循环一次内层用Map.get()查找共同用户时间复杂度是O(nm)而不是双重遍历的O(n×m)。我一开始图省事写了两重循环商品数到8000多的时候计算一次要半小时改用单层遍历找交集后直接降到分钟级。4.2 物品相似度矩阵构建与用户推荐主流程物品相似度矩阵是整个推荐引擎的核心资产。构建流程是先把“用户-商品”评分数据转成商品视角的“商品-用户评分映射”再针对有效商品对计算相似度。Service Slf4j public class ItemCFRecommender { // 相似度阈值低于该值的商品对直接丢弃避免矩阵过于庞大 private static final double SIMILARITY_THRESHOLD 0.3; // 推荐TopN数量 private static final int TOP_N 20; Resource private CosineSimilarity cosineSimilarity; /** * 构建商品相似度矩阵 * * param userItemMap 用户-商品评分映射key为userIdvalue为商品评分映射 * return 商品相似度矩阵key为商品Idvalue为该商品与其它商品的相似度映射 */ private MapLong, MapLong, Double buildItemSimilarityMatrix( MapLong, MapLong, Double userItemMap) { // Step1: 商品-用户评分映射转换 MapLong, MapLong, Double itemUserMap new HashMap(); for (Map.EntryLong, MapLong, Double userEntry : userItemMap.entrySet()) { Long userId userEntry.getKey(); MapLong, Double itemScores userEntry.getValue(); for (Map.EntryLong, Double itemEntry : itemScores.entrySet()) { itemUserMap.computeIfAbsent(itemEntry.getKey(), k - new HashMap()) .put(userId, itemEntry.getValue()); } } ListLong itemIds new ArrayList(itemUserMap.keySet()); MapLong, MapLong, Double similarityMatrix new HashMap(); // Step2: 两两计算商品相似度 for (int i 0; i itemIds.size(); i) { Long itemId1 itemIds.get(i); MapLong, Double vector1 itemUserMap.get(itemId1); for (int j i 1; j itemIds.size(); j) { Long itemId2 itemIds.get(j); MapLong, Double vector2 itemUserMap.get(itemId2); double similarity cosineSimilarity.calculate(vector1, vector2); if (similarity SIMILARITY_THRESHOLD) { similarityMatrix.computeIfAbsent(itemId1, k - new HashMap()).put(itemId2, similarity); similarityMatrix.computeIfAbsent(itemId2, k - new HashMap()).put(itemId1, similarity); } } } log.info(商品相似度矩阵构建完成, 商品数量{}, 相似关系数量{}, itemIds.size(), similarityMatrix.values().stream().mapToInt(Map::size).sum()); return similarityMatrix; } /** * 为用户生成TopN推荐列表 * * param userId 用户ID * param userActions 该用户的行为数据 * param similarityMatrix 商品相似度矩阵 * return 推荐商品ID列表 */ private ListLong recommendForUser(Long userId, ListUserAction userActions, MapLong, MapLong, Double similarityMatrix) { // 1. 获取用户有过行为的商品及评分 MapLong, Double interactedItems new HashMap(); for (UserAction action : userActions) { interactedItems.merge(action.getProductId(), action.getActionScore(), Double::sum); } // 2. 计算候选商品的推荐得分 MapLong, Double scoreMap new HashMap(); for (Map.EntryLong, Double entry : interactedItems.entrySet()) { Long itemId entry.getKey(); Double userScore entry.getValue(); // 找和当前商品相似的商品 MapLong, Double similarItems similarityMatrix.getOrDefault(itemId, Collections.emptyMap()); for (Map.EntryLong, Double simEntry : similarItems.entrySet()) { Long candidateId simEntry.getKey(); // 用户已经交互过的商品不重复推荐 if (interactedItems.containsKey(candidateId)) { continue; } double simScore simEntry.getValue(); scoreMap.merge(candidateId, userScore * simScore, Double::sum); } } // 3. 按推荐分降序取TopN return scoreMap.entrySet().stream() .sorted(Map.Entry.Long, DoublecomparingByValue().reversed()) .limit(TOP_N) .map(Map.Entry::getKey) .collect(Collectors.toList()); } }这段代码的核心逻辑其实非常简洁——每个候选商品的推荐分数等于“用户已有行为的商品评分”乘以“该商品与候选商品的相似度”的累加值。这个分数越大说明这个候选商品越可能被用户喜欢。我遇到过好多初学者卡在“相似度矩阵构建”这一步因为这是整个算法中时间复杂度最高的环节。建议你开发时先用小数据集比如1000商品、5000行为跑通流程确认结果合理后再放大数据。而且要加SIMILARITY_THRESHOLD阈值过滤——不加的话相似度矩阵会是个稠密矩阵内存直接撑爆。4.3 冷启动问题的兜底策略协同过滤算法有个绕不开的痛点冷启动。新用户没有任何行为数据新商品没有任何交互记录算法算不出来推荐结果。我的处理策略是分两层降级。对新用户行为记录少于3条推荐结果不从协同过滤引擎取而是返回热门商品榜。热门榜的计算公式要考虑“浏览量 收藏量 成交优先级”我用的排序分数如下public Double calculateHotScore(Product product) { // 加权公式收藏权重高于浏览 return product.getViewCount() * 1.0 product.getFavoriteCount() * 5.0 product.getTradeCount() * 15.0; }对新商品也就是上架时间在48小时内且还没有任何用户行为的商品把它放到“最新发布”推荐位。这样既能解决冷启动也能帮卖家快速获得曝光。这两个策略都集成在推荐Service里当协同过滤结果为空或不足N个时自动补位。5. 推荐接口设计、前端联调与Redis缓存5.1 推荐接口定义与返回结构设计推荐系统对外暴露的接口要设计得足够简洁前端只需要传一个用户标识和数量参数后端返回商品列表就行。接口定义如下RestController RequestMapping(/api/recommend) Slf4j public class RecommendController { Resource private RecommendService recommendService; /** * 获取用户个性化推荐列表 * * param userId 用户ID * param limit 返回数量默认10 */ GetMapping(/products) public ResultListProductVO getRecommendProducts( RequestParam(userId) Long userId, RequestParam(value limit, defaultValue 10) Integer limit) { ListProductVO products recommendService.getRecommendProducts(userId, limit); return Result.success(products); } }返回结构统一封装成一个泛型ResultT包含code、message、data三个字段。这样前端处理业务状态时有一套固定的逻辑不需要每个接口各自定义一套返回格式联调体验会好很多。ProductVO里除了商品的基本属性还会带上recommendReason字段比如“因为你看过《宜家书桌》”这个字段虽然简单但能明显提升推荐结果的说服力和用户体验。5.2 Redis缓存策略与降级逻辑推荐算法是离线算好的但用户请求是实时到达的。所以在Service层必须把Redis缓存用好这也是整个项目响应速度的关键。缓存Key的设计我用的是recommend:{userId}:{limit}的格式。很明显不同userId的结果不能共享而同一个用户请求10条和请求20条的推荐结果也不同所以把limit也放进Key里。实际开发中我做了个优化——把Top20的推荐一次性算好放进缓存用户请求10条就从缓存里截取10条不用为不同limit重复缓存多份内存占用更省。核心的缓存读取逻辑Override public ListProductVO getRecommendProducts(Long userId, Integer limit) { // 1. 先查Redis缓存 String cacheKey RedisKeyUtil.buildRecommendKey(userId); String cacheValue redisTemplate.opsForValue().get(cacheKey); if (StringUtils.hasText(cacheValue)) { ListLong productIds JSON.parseArray(cacheValue, Long.class); return productService.listByIdsWithDetail(productIds.stream().limit(limit).collect(Collectors.toList())); } // 2. 缓存未命中查MySQL中的推荐结果表 ListLong productIds recommendResultMapper.selectTopNByUserId(userId, limit); if (CollectionUtils.isNotEmpty(productIds)) { // 异步刷新缓存 refreshCache(userId); return productService.listByIdsWithDetail(productIds); } // 3. 连MySQL结果都没有兜底返回热门商品 return popularProductService.listHotProducts(limit); }这段降级逻辑在真实项目中极其重要。我遇到过定时任务还没跑完用户就发起了推荐请求的情况——如果没有兜底策略接口会直接返回空列表或者报错这个体验是很糟糕的。降级到热门商品的策略保证不管系统处于什么状态用户的请求始终有响应只是推荐个性化程度不同而已。5.3 推荐结果可视化前端展示的工程化思路虽然这个项目的主体是后端但推荐结果的展示效果直接决定了系统的成败。前端我用的是Vue 2 Element UI的组合推荐模块大致分三个区块“为你推荐”横向滑动卡片这是协同过滤的主推荐位。“看了又看”商品详情页底部的相似推荐基于当前商品的相似度矩阵。“人气热卖”列表冷启动兜底位也是新手用户的主推位。用户在“为你推荐”区的行为点击/收藏会同步上报到后台作为下一轮协同过滤计算的输入这就形成了一个良性循环推荐越准用户点击越多点击越多算法学习到的数据越多推荐就更准。做前端联调的时候有一个很实用的细节推荐接口返回的recommendReason字段不要浪费。前端在推荐卡片右下角展示“和你收藏的XX相似”“热门推荐”“你关注的人也在看”等标签点击率实测会有明显提升因为用户能理解“为什么这个东西会出现在我面前”对推荐结果的信任感会强很多。6. 常见问题排查与性能优化实战6.1 算法运行慢矩阵计算性能瓶颈与优化系统上线初期最典型的性能问题是推荐计算任务跑得太慢用户刷新接口后很久看不到推荐内容。我最初跑一次全量计算需要15分钟左右后来优化到了2分钟以内。优化措施有三板斧第一招加稀疏矩阵优化只存储有交互数据的用户-商品对不存储空值格子。第二招加相似度阈值过滤低于0.3的相似度直接丢弃矩阵从稠密变稀疏。第三招也是核心——加共现商品对筛选。相似度计算前先找出“同时被至少2个用户行为过”的商品对只对这些商品对做计算。因为被不同用户行为过的商品对才有相似度计算价值从没共同出现过的商品对计算出来也是0或接近0纯属浪费CPU。还有一招更省事的——直接加机器配置。我用本地开发机8G内存跑全量计算会吃力换到服务器16G内存后压力小了很多。但是算法优化优先于硬件升级代码写得好才是根本。6.2 Redis缓存穿透与缓存雪崩的处理推荐系统用的是Redis缓存那就一定会遇到缓存穿透和缓存雪崩问题。我讲讲实际开发中踩到的两个教训。缓存穿透的场景某个新注册用户没有任何行为数据协同过滤结果表里也没有他的记录Redis当然也没有缓存。如果大量新用户同时在系统注册并请求推荐接口每个请求都会穿透Redis打到MySQLMySQL瞬间就会扛不住。解决方式是加空值缓存——即使推荐结果为空也把空结果缓存1分钟防止穿透。另外接口层面用布隆过滤器做用户ID有效性校验也是一道防线。缓存雪崩的场景推荐定时任务在每天零点统一计算结果写入Redis时设置了完全一样的过期时间那么所有缓存在同一秒到期同时回源MySQL数据库连接池直接被打满。解决方式很粗暴但有效缓存过期时间引入随机因子比如基础10分钟再随机加1-5分钟。我后来实测这个随机化之后缓存批量失效的情况基本消失了。6.3 数据稀疏导致的推荐质量差算法调参与数据增强还有一类问题是推荐结果“不聪明”。用户行为数据少评分矩阵稀疏度高达95%以上协同过滤算法会退化成“热门推荐”或“随机推荐”用户感知不到个性化。面对这种情况我用了两个策略。第一降低冷启动判定阈值。默认“有3条行为才算老用户”实际数据分析后发现跳蚤市场大部分用户的行为记录都在5条以下如果把阈值设为5覆盖的用户比例太窄。降为2条之后能够命中协同过滤的用户覆盖率高了很多。第二引入用户画像辅助。在协同过滤结果基础上叠加用户偏好分类——用户收藏最多的商品品类在推荐列表中按比例提升该品类的权重。这个策略虽然不完全属于协同过滤的范畴但和协同过滤结合后推荐列表的点击率提升是很明显的。下面把我踩过的坑整理成速查表方便你直接对照排查问题现象可能原因解决方案推荐任务耗时过长未做共现商品对筛选增加“至少被2个用户共同行为”过滤推荐结果几乎全是热门商品评分矩阵太稀疏降低冷启动阈值增加用户画像辅助用户刷新接口很慢Redis缓存未命中检查缓存Key的拼接格式是否一致用户反馈“推荐的都是看过的”未在算法中过滤已交互商品在候选集生成阶段排除interactedItems定时任务执行了但推荐没更新Scheduled被阻塞配置独立的定时线程池商品下架后仍在推荐列表推荐结果表未同步状态推荐查询时关联t_product.status过滤新商品没有曝光机会冷启动未处理新商品增加“最新发布”推荐位6.4 Jackson序列化和Long型精度丢失问题最后分享一个所有Java后端都会踩的经典坑当推荐结果中的商品ID数据库里是bigint类型大于Java的Long最大值边界转成JSON传给前端时JavaScript的Number类型会丢失精度。跳蚤市场的商品ID如果用了雪花算法生成19位ID传给前端后最后几位数字会变成0导致用户点击商品详情时ID错误、页面报404。解决方案有两个二选一即可。第一种是把实体类的id字段类型改成String只做展示不参与运算。第二种是在Jackson配置中注册ToStringSerializer序列化时把Long自动转成字符串。我用的第二种因为改动侵入性最小Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(Long.TYPE, ToStringSerializer.instance); }; } }这一行配置解决了从前端传参到后端查询的整个链路精度问题。这种坑用一句话总结就是后端交付的不只是接口而是前后端都能正确协作的数据契约。7. 一些实操心得与扩展建议7.1 从零到一跑通项目的建议顺序如果你正在做类似的推荐系统项目我的建议是按照下面这个顺序推进能少走很多弯路第一步先把Spring Boot的基础框架搭好用假数据写死一个推荐结果接口把前后端的数据链路跑通。第二步实现数据采集模块把浏览、收藏这些行为记录到数据库。第三步实现算法模块先用小数据集几百条行为记录跑通协同过滤流程。第四步写定时任务把离线计算的结果同步到Redis和推荐结果表。第五步接入真实数据观察推荐效果做参数调优。不要一上来就埋头写算法也不要一上来就搭复杂架构。先把一条最简单的主链路跑通再逐步丰富细节这个节奏是最稳的。7.2 后续扩展方向的思考如果你想把项目做深做远有几个很自然的扩展方向。算法层面可以尝试把协同过滤和内容推荐融合做混合推荐——用协同过滤捕捉行为模式用内容推荐补充冷启动和新商品曝光能力。性能层面如果用户量级到百万以上可以把离线计算迁移到Spark或Flink上用分布式计算框架替代单机算法。工程层面还可以加上A/B测试机制用实验数据验证不同算法策略的效果让推荐系统的迭代有数据依据而不是拍脑袋。最后说一点我的真实体会推荐系统最难的其实不是算法本身而是“数据质量”和“业务理解”这两件事。协同过滤算法的原理一天就能搞懂但把行为数据采集准确、把业务规则融入推荐流程、把冷启动和降级策略做到位这些才是项目真正的价值所在。尤其是跳蚤市场这个场景它的小众和杂糅属性恰恰给了做“小而美”推荐系统一个非常合适的切入口希望这篇实战总结能给你带来一些踏实的参考。 
长河君 · 2026/10/11 3:37:00 · 阅读 1.2k Spring Boot集成协同过滤算法：跳蚤市场商品推荐系统实战
做跳蚤市场的商品推荐系统最头疼的不是Spring Boot怎么写而是“协同过滤算法怎么落地”。我接手这个项目的时候也踩了不少坑——从算法选型到数据表设计从相似度计算到冷启动处理每一步都有讲究。这篇项目总结就围绕“springboot 协同过滤算法 跳蚤市场商品推荐”这条主线把我在实际开发中的设计思路、核心代码、踩坑记录和优化经验完整分享出来希望给正在做同类系统尤其是毕设或者个人项目的朋友一个可直接参考的模板。1. 项目整体设计与算法选型解析1.1 跳蚤市场场景下的推荐需求拆解跳蚤市场和常规电商平台最大的区别在于商品是个人卖家发布的闲置物品品类杂、数量少、生命周期短而且大部分商品没有销量数据。这种情况下做推荐系统如果直接照搬淘宝那种基于用户行为的复杂推荐架构肯定行不通。先拆一下业务需求。跳蚤市场里用户的核心行为就三类浏览商品、收藏商品、发布商品。而推荐系统的目标很直白——在用户打开首页时给他推送“可能感兴趣”的闲置商品提高浏览深度和成交概率。推荐策略上我选了协同过滤算法作为核心引擎原因有三个跳蚤市场的商品没有统一的属性标准比如成色、价格区间浮动大基于内容的推荐需要大量人工标注特征工程成本太高。协同过滤不关心商品“是什么”只看用户和商品的交互行为矩阵天然适合这种缺乏结构化特征的场景。跳蚤市场用户基数不大一般校内或社区级别协同过滤的计算量完全可控不需要上重型的分布式计算框架。具体算法路径上我采用的是“基于物品的协同过滤ItemCF为主基于用户的协同过滤UserCF为辅”的双通道策略。为什么主用ItemCF因为跳蚤市场的用户兴趣变化快今天想买书架明天可能想看键盘ItemCF能根据“当前浏览了某商品”立刻推荐相似商品实时性好而UserCF更适合发现新兴趣但计算代价大、实时性差适合做离线兜底推荐。1.2 技术栈选型与版本确认这个项目的技术底座就是标题里的Spring Boot。选Spring Boot而不是Spring MVC或SSH核心原因是它能把“配置地狱”变成“自动装配”尤其在整合MyBatis、Redis这些组件时依赖管理和配置项都省心很多。我用的版本组合如下已实测跑通组件版本说明JDK1.8稳定兼容性好不推荐JDK 17踩坑Spring Boot2.7.x2.x系列最成熟的末班车3.x坑多且部分依赖不兼容MyBatis-Plus3.5.x单表操作零SQL推荐模块需要写复杂SQL时才用原生Redis5.x/6.x缓存推荐结果降低算法重复计算的压MySQL5.7/8.0存储用户、商品、行为、推荐结果四类数据Maven3.6项目构建和依赖管理有一个很实际的提醒Spring Boot版本不要盲目追新。我一开始试过Spring Boot 3.2 JDK 21结果MyBatis-Plus的旧版本和Jakarta命名空间冲突折腾了一整天。后来退回2.7.x所有依赖一键解决。做项目稳定性永远比新特性重要。1.3 为什么协同过滤在Spring Boot中适合离线计算 缓存回源在Spring Boot里集成协同过滤算法有一个很关键的设计决策算法计算不可能在每次用户刷新页面时实时跑一遍。原因很简单假设商品数量是1万用户是1万构建评分矩阵就要做亿级别的运算如果在请求线程里同步执行接口响应时间直接爆炸。所以整体架构上我采用了“离线计算、缓存回源”的模式定时任务Spring Scheduled每次固定时间去计算协同过滤推荐结果写入Redis。用户请求推荐接口时先从Redis取缓存结果如果缓存命中就直接返回。Redis里没有数据时降级方案是查MySQL里最近一次计算的推荐结果表或者干脆返回热门商品列表保证接口不报错。这套设计把“算法耗时”和“接口响应快”这两个矛盾拆开了算法多慢都无所谓反正后台算用户感知不到接口只查缓存响应时间稳定在几十毫秒以内。完整架构流程可以理解成用户行为日志 - MySQL行为表 - 离线定时任务读取 - 构建评分矩阵 - 计算相似度 - 生成TopN推荐 - 写入Redis - 用户请求 - 读取Redis缓存 - 返回推荐结果这个流程中Spring Boot扮演的是“连接器”的角色定时调度、数据读写、缓存管理、接口暴露全部由它承担协同过滤算法则作为核心引擎以Service层组件的形式嵌入到业务逻辑里。2. 核心算法原理与实现步骤2.1 评分矩阵的构建行为权重怎么设协同过滤算法第一步是把用户行为转化成“用户-商品”评分矩阵。跳蚤市场不像电商有明确的星级评分所以我需要把隐式反馈换算成分数。这里分享我用的权重规则实测效果还算合理用户行为行为描述评分权重浏览点击商品详情页停留超过5秒1分收藏点击收藏按钮表示强意向2分发布用户自己发布了相似品类的商品1.5分购买/求购交易成功或发起求购3分需要说明的是浏览行为的判定不能只看“点没点”要配合停留时长。我做过测试如果只要点击就给分首页推荐位会被那些“只看图不点详情”的无效浏览刷爆推荐质量明显下降。所以数据采集时前端需要上报停留时长后端过滤掉停留小于5秒的浏览记录。评分矩阵的结构是稀疏矩阵用户数×商品数绝大多数格子都是空的。处理这种稀疏矩阵Java里最省内存的方式是用MapLong, MapLong, Double嵌套结构外层key是userId内层key是itemIdvalue是评分值。这样只存储有效交互数据不会因为矩阵过大撑爆内存。2.2 相似度计算余弦相似度的选择与实现基于物品的协同过滤核心是计算商品之间的相似度。相似度公式有很多种——余弦相似度、皮尔逊相关系数、Jaccard相似度我最终选了余弦相似度。原因是它在处理稀疏数据时表现稳定而且实现简单计算效率高。余弦相似度的计算逻辑把每个商品看成一个向量向量维度是所有用户向量的值是用户对该商品的评分。两个商品向量的夹角越小说明喜欢这两个商品的用户群体越重合商品就越相似。公式记作cos(θ) (A · B) / (|A| × |B|)其中A · B是两向量的点积|A|是向量A的模长。具体的Java实现我放在了更后面的代码章节。计算时有个很关键的小技巧在计算相似度之前要做“反向索引”优化。如果直接双重遍历所有商品算相似度1万个商品就要算近5000万对性能完全扛不住。常规做法是先筛选出“有共同评分用户”的商品对只算这些有交集的组合。我计算时发现加了这层筛选后相似度计算时间从十几分钟降到了几十秒效果立竿见影。2.3 推荐候选集生成与TopN排序有了商品之间的相似度矩阵给用户推荐就很简单了原理就是一句话找到用户最近交互过的商品找出和这些商品最相似的其它商品排除掉用户已经买过或看过的商品按综合分数排序取前N个。推荐分数的计算方式我采用的是累加模式预测用户u对商品i的评分 Σ(用户u对商品j的行为评分 × 商品i与商品j的相似度)其中商品j是用户u最近有过正反馈行为的商品集合商品i是候选商品。经过这次累加后每个候选商品都会得到一个综合推荐分降序排列取前N个就是最终的推荐列表。这里还有一个业务规则要处理跳蚤市场每个用户自己发布的商品不应该出现在自己的推荐列表里。另外被下架、已售出的商品也要在推荐前过滤掉。这些规则我放在RecommendFilter组件里统一处理避免每个接口都重复写过滤逻辑。3. Spring Boot工程搭建与数据库设计3.1 Maven项目结构与依赖配置项目结构遵循Spring Boot规范的分层架构Maven依赖主要集中在pom.xml里。这里给出核心依赖配置parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies !-- Web 核心 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus 持久层 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency !-- Redis 缓存 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency !-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency !-- Lombok简化实体类 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies项目结构上我这里用了比较标准的代码分层src/main/java/com/example/fleamarket ├── controller # REST接口层 │ ├── RecommendController.java │ ├── ProductController.java │ └── UserController.java ├── service # 业务逻辑层 │ ├── recommend │ │ ├── ItemCFRecommender.java # 协同过滤核心算法 │ │ ├── RecommendCacheService.java │ │ └── RecommendScheduleTask.java │ ├── product │ └── user ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库实体类 ├── config # 配置类Redis、MyBatis等 └── common # 通用工具与返回结果封装这样的划分逻辑很明确controller只负责参数接收和结果返回service专注业务规则推荐算法单独放一个包隔离起来方便后续替换算法策略而不影响其它模块。3.2 数据库核心表设计用户、商品、行为表数据库设计是整个推荐系统的地基表结构一旦定死后期返工成本极高。我设计了5张核心表下面给出每张表的用途和关键字段。用户表t_user和普通电商用户表没有本质区别重点字段是user_id、nickname、avatar、create_time。跳蚤市场可以加一个credit_score信用分字段方便做用户信用分层但这和推荐算法本身关系不大不展开。商品表t_product是推荐系统最核心的数据来源之一关键字段设计如下CREATE TABLE t_product ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 商品ID, title varchar(128) NOT NULL COMMENT 商品标题, description text COMMENT 商品描述, category_id bigint(20) DEFAULT NULL COMMENT 商品分类ID, price decimal(10,2) DEFAULT NULL COMMENT 价格元, original_price decimal(10,2) DEFAULT NULL COMMENT 原价, seller_id bigint(20) NOT NULL COMMENT 发布者ID, status tinyint(4) DEFAULT 1 COMMENT 状态1上架 0下架 2已售出, cover_image varchar(255) DEFAULT NULL COMMENT 封面图URL, view_count int(11) DEFAULT 0 COMMENT 浏览次数, favorite_count int(11) DEFAULT 0 COMMENT 收藏次数, create_time datetime DEFAULT NULL COMMENT 发布时间, PRIMARY KEY (id), KEY idx_seller_id (seller_id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;给category_id和seller_id建索引非常重要。推荐算法在过滤和筛选时经常按这两个字段做查询没有索引的话在商品数据量过万后SQL性能会明显下降。用户行为表t_user_action是推荐系统的“燃料”协同过滤算法的数据源就是它CREATE TABLE t_user_action ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, product_id bigint(20) NOT NULL COMMENT 商品ID, action_type tinyint(4) NOT NULL COMMENT 行为类型1浏览 2收藏 3发布 4购买/求购, action_score double DEFAULT 1 COMMENT 行为评分权重, create_time datetime DEFAULT NULL COMMENT 行为时间, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_product_id (product_id), KEY idx_user_product (user_id, product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户行为表;联合索引idx_user_product是推荐系统最常用的查询路径——“查某个用户的所有行为”“查某个商品被哪些用户行为过”这两种查询都会命中这个索引务必加上。另外行为数据只增不改非常适合定时批量处理所以这张表没有设计更新时间字段。另外还需要一个推荐结果表t_recommend_result存储离线计算的推荐结果用于缓存未命中时的兜底查询。以及一个定时任务执行记录表t_recommend_task_log用来记录每次推荐计算的开始时间、耗时、生成结果数量。3.3 定时任务框架搭建离线计算的调度入口协同过滤是离线计算的定时任务用Spring Boot自带的Scheduled就能搞定。推荐计算的触发策略我设置为每10分钟执行一次原因很实在跳蚤市场的用户活跃高峰和商品新增速度都比较快如果每小时算一次用户看到的新商品推荐可能会滞后如果每1分钟算一次商品向量还没来得及更新计算意义不大也浪费资源。定时任务代码骨架如下Component Slf4j public class RecommendScheduleTask { Resource private ItemCFRecommender itemCFRecommender; Resource private RecommendCacheService cacheService; // 每10分钟执行一次推荐计算 Scheduled(cron 0 */10 * * * ?) public void runRecommend() { long startTime System.currentTimeMillis(); log.info(推荐计算任务开始, time{}, startTime); try { // 1. 加载用户行为数据 ListUserAction actions loadUserActions(); // 2. 执行协同过滤核心计算生成每个用户的TopN推荐 MapLong, ListLong recommendMap itemCFRecommender.recommendForAllUsers(actions); // 3. 将推荐结果写入Redis和MySQL cacheService.saveRecommendResult(recommendMap); } catch (Exception e) { log.error(推荐计算失败, e); } long costTime System.currentTimeMillis() - startTime; log.info(推荐计算任务结束, 耗时{}ms, costTime); } }有一点经验要说明Scheduled默认是单线程串行执行的如果有多个定时任务都要跑建议在配置类里显式声明一个线程池避免多个任务排队互相阻塞。我是这样配置的Configuration public class ScheduleConfig implements SchedulingConfigurer { Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setScheduler(Executors.newScheduledThreadPool(5)); } }4. 协同过滤算法核心代码实现4.1 余弦相似度计算的Java实现算法核心代码是整个项目的灵魂我特意把它独立成工具类保证业务代码和算法代码解耦。先看余弦相似度的实现Component public class CosineSimilarity { /** * 计算两个商品向量的余弦相似度 * * param vector1 商品1的评分向量key为userIdvalue为评分 * param vector2 商品2的评分向量key为userIdvalue为评分 * return 相似度值范围[-1, 1]越大越相似 */ public double calculate(MapLong, Double vector1, MapLong, Double vector2) { // 分子点积 double dotProduct 0.0; // 分母两个向量的模长乘积 double norm1 0.0; double norm2 0.0; // 遍历向量1的每个维度同时在向量2中查找共同维度 for (Map.EntryLong, Double entry : vector1.entrySet()) { Long userId entry.getKey(); double score1 entry.getValue(); norm1 score1 * score1; Double score2 vector2.get(userId); if (score2 ! null) { dotProduct score1 * score2; } } // 计算向量2的模长 for (Double score : vector2.values()) { norm2 score * score; } if (norm1 0.0 || norm2 0.0) { return 0.0; } return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); } }计算实现中要注意的是遍历只在外层循环一次内层用Map.get()查找共同用户时间复杂度是O(nm)而不是双重遍历的O(n×m)。我一开始图省事写了两重循环商品数到8000多的时候计算一次要半小时改用单层遍历找交集后直接降到分钟级。4.2 物品相似度矩阵构建与用户推荐主流程物品相似度矩阵是整个推荐引擎的核心资产。构建流程是先把“用户-商品”评分数据转成商品视角的“商品-用户评分映射”再针对有效商品对计算相似度。Service Slf4j public class ItemCFRecommender { // 相似度阈值低于该值的商品对直接丢弃避免矩阵过于庞大 private static final double SIMILARITY_THRESHOLD 0.3; // 推荐TopN数量 private static final int TOP_N 20; Resource private CosineSimilarity cosineSimilarity; /** * 构建商品相似度矩阵 * * param userItemMap 用户-商品评分映射key为userIdvalue为商品评分映射 * return 商品相似度矩阵key为商品Idvalue为该商品与其它商品的相似度映射 */ private MapLong, MapLong, Double buildItemSimilarityMatrix( MapLong, MapLong, Double userItemMap) { // Step1: 商品-用户评分映射转换 MapLong, MapLong, Double itemUserMap new HashMap(); for (Map.EntryLong, MapLong, Double userEntry : userItemMap.entrySet()) { Long userId userEntry.getKey(); MapLong, Double itemScores userEntry.getValue(); for (Map.EntryLong, Double itemEntry : itemScores.entrySet()) { itemUserMap.computeIfAbsent(itemEntry.getKey(), k - new HashMap()) .put(userId, itemEntry.getValue()); } } ListLong itemIds new ArrayList(itemUserMap.keySet()); MapLong, MapLong, Double similarityMatrix new HashMap(); // Step2: 两两计算商品相似度 for (int i 0; i itemIds.size(); i) { Long itemId1 itemIds.get(i); MapLong, Double vector1 itemUserMap.get(itemId1); for (int j i 1; j itemIds.size(); j) { Long itemId2 itemIds.get(j); MapLong, Double vector2 itemUserMap.get(itemId2); double similarity cosineSimilarity.calculate(vector1, vector2); if (similarity SIMILARITY_THRESHOLD) { similarityMatrix.computeIfAbsent(itemId1, k - new HashMap()).put(itemId2, similarity); similarityMatrix.computeIfAbsent(itemId2, k - new HashMap()).put(itemId1, similarity); } } } log.info(商品相似度矩阵构建完成, 商品数量{}, 相似关系数量{}, itemIds.size(), similarityMatrix.values().stream().mapToInt(Map::size).sum()); return similarityMatrix; } /** * 为用户生成TopN推荐列表 * * param userId 用户ID * param userActions 该用户的行为数据 * param similarityMatrix 商品相似度矩阵 * return 推荐商品ID列表 */ private ListLong recommendForUser(Long userId, ListUserAction userActions, MapLong, MapLong, Double similarityMatrix) { // 1. 获取用户有过行为的商品及评分 MapLong, Double interactedItems new HashMap(); for (UserAction action : userActions) { interactedItems.merge(action.getProductId(), action.getActionScore(), Double::sum); } // 2. 计算候选商品的推荐得分 MapLong, Double scoreMap new HashMap(); for (Map.EntryLong, Double entry : interactedItems.entrySet()) { Long itemId entry.getKey(); Double userScore entry.getValue(); // 找和当前商品相似的商品 MapLong, Double similarItems similarityMatrix.getOrDefault(itemId, Collections.emptyMap()); for (Map.EntryLong, Double simEntry : similarItems.entrySet()) { Long candidateId simEntry.getKey(); // 用户已经交互过的商品不重复推荐 if (interactedItems.containsKey(candidateId)) { continue; } double simScore simEntry.getValue(); scoreMap.merge(candidateId, userScore * simScore, Double::sum); } } // 3. 按推荐分降序取TopN return scoreMap.entrySet().stream() .sorted(Map.Entry.Long, DoublecomparingByValue().reversed()) .limit(TOP_N) .map(Map.Entry::getKey) .collect(Collectors.toList()); } }这段代码的核心逻辑其实非常简洁——每个候选商品的推荐分数等于“用户已有行为的商品评分”乘以“该商品与候选商品的相似度”的累加值。这个分数越大说明这个候选商品越可能被用户喜欢。我遇到过好多初学者卡在“相似度矩阵构建”这一步因为这是整个算法中时间复杂度最高的环节。建议你开发时先用小数据集比如1000商品、5000行为跑通流程确认结果合理后再放大数据。而且要加SIMILARITY_THRESHOLD阈值过滤——不加的话相似度矩阵会是个稠密矩阵内存直接撑爆。4.3 冷启动问题的兜底策略协同过滤算法有个绕不开的痛点冷启动。新用户没有任何行为数据新商品没有任何交互记录算法算不出来推荐结果。我的处理策略是分两层降级。对新用户行为记录少于3条推荐结果不从协同过滤引擎取而是返回热门商品榜。热门榜的计算公式要考虑“浏览量 收藏量 成交优先级”我用的排序分数如下public Double calculateHotScore(Product product) { // 加权公式收藏权重高于浏览 return product.getViewCount() * 1.0 product.getFavoriteCount() * 5.0 product.getTradeCount() * 15.0; }对新商品也就是上架时间在48小时内且还没有任何用户行为的商品把它放到“最新发布”推荐位。这样既能解决冷启动也能帮卖家快速获得曝光。这两个策略都集成在推荐Service里当协同过滤结果为空或不足N个时自动补位。5. 推荐接口设计、前端联调与Redis缓存5.1 推荐接口定义与返回结构设计推荐系统对外暴露的接口要设计得足够简洁前端只需要传一个用户标识和数量参数后端返回商品列表就行。接口定义如下RestController RequestMapping(/api/recommend) Slf4j public class RecommendController { Resource private RecommendService recommendService; /** * 获取用户个性化推荐列表 * * param userId 用户ID * param limit 返回数量默认10 */ GetMapping(/products) public ResultListProductVO getRecommendProducts( RequestParam(userId) Long userId, RequestParam(value limit, defaultValue 10) Integer limit) { ListProductVO products recommendService.getRecommendProducts(userId, limit); return Result.success(products); } }返回结构统一封装成一个泛型ResultT包含code、message、data三个字段。这样前端处理业务状态时有一套固定的逻辑不需要每个接口各自定义一套返回格式联调体验会好很多。ProductVO里除了商品的基本属性还会带上recommendReason字段比如“因为你看过《宜家书桌》”这个字段虽然简单但能明显提升推荐结果的说服力和用户体验。5.2 Redis缓存策略与降级逻辑推荐算法是离线算好的但用户请求是实时到达的。所以在Service层必须把Redis缓存用好这也是整个项目响应速度的关键。缓存Key的设计我用的是recommend:{userId}:{limit}的格式。很明显不同userId的结果不能共享而同一个用户请求10条和请求20条的推荐结果也不同所以把limit也放进Key里。实际开发中我做了个优化——把Top20的推荐一次性算好放进缓存用户请求10条就从缓存里截取10条不用为不同limit重复缓存多份内存占用更省。核心的缓存读取逻辑Override public ListProductVO getRecommendProducts(Long userId, Integer limit) { // 1. 先查Redis缓存 String cacheKey RedisKeyUtil.buildRecommendKey(userId); String cacheValue redisTemplate.opsForValue().get(cacheKey); if (StringUtils.hasText(cacheValue)) { ListLong productIds JSON.parseArray(cacheValue, Long.class); return productService.listByIdsWithDetail(productIds.stream().limit(limit).collect(Collectors.toList())); } // 2. 缓存未命中查MySQL中的推荐结果表 ListLong productIds recommendResultMapper.selectTopNByUserId(userId, limit); if (CollectionUtils.isNotEmpty(productIds)) { // 异步刷新缓存 refreshCache(userId); return productService.listByIdsWithDetail(productIds); } // 3. 连MySQL结果都没有兜底返回热门商品 return popularProductService.listHotProducts(limit); }这段降级逻辑在真实项目中极其重要。我遇到过定时任务还没跑完用户就发起了推荐请求的情况——如果没有兜底策略接口会直接返回空列表或者报错这个体验是很糟糕的。降级到热门商品的策略保证不管系统处于什么状态用户的请求始终有响应只是推荐个性化程度不同而已。5.3 推荐结果可视化前端展示的工程化思路虽然这个项目的主体是后端但推荐结果的展示效果直接决定了系统的成败。前端我用的是Vue 2 Element UI的组合推荐模块大致分三个区块“为你推荐”横向滑动卡片这是协同过滤的主推荐位。“看了又看”商品详情页底部的相似推荐基于当前商品的相似度矩阵。“人气热卖”列表冷启动兜底位也是新手用户的主推位。用户在“为你推荐”区的行为点击/收藏会同步上报到后台作为下一轮协同过滤计算的输入这就形成了一个良性循环推荐越准用户点击越多点击越多算法学习到的数据越多推荐就更准。做前端联调的时候有一个很实用的细节推荐接口返回的recommendReason字段不要浪费。前端在推荐卡片右下角展示“和你收藏的XX相似”“热门推荐”“你关注的人也在看”等标签点击率实测会有明显提升因为用户能理解“为什么这个东西会出现在我面前”对推荐结果的信任感会强很多。6. 常见问题排查与性能优化实战6.1 算法运行慢矩阵计算性能瓶颈与优化系统上线初期最典型的性能问题是推荐计算任务跑得太慢用户刷新接口后很久看不到推荐内容。我最初跑一次全量计算需要15分钟左右后来优化到了2分钟以内。优化措施有三板斧第一招加稀疏矩阵优化只存储有交互数据的用户-商品对不存储空值格子。第二招加相似度阈值过滤低于0.3的相似度直接丢弃矩阵从稠密变稀疏。第三招也是核心——加共现商品对筛选。相似度计算前先找出“同时被至少2个用户行为过”的商品对只对这些商品对做计算。因为被不同用户行为过的商品对才有相似度计算价值从没共同出现过的商品对计算出来也是0或接近0纯属浪费CPU。还有一招更省事的——直接加机器配置。我用本地开发机8G内存跑全量计算会吃力换到服务器16G内存后压力小了很多。但是算法优化优先于硬件升级代码写得好才是根本。6.2 Redis缓存穿透与缓存雪崩的处理推荐系统用的是Redis缓存那就一定会遇到缓存穿透和缓存雪崩问题。我讲讲实际开发中踩到的两个教训。缓存穿透的场景某个新注册用户没有任何行为数据协同过滤结果表里也没有他的记录Redis当然也没有缓存。如果大量新用户同时在系统注册并请求推荐接口每个请求都会穿透Redis打到MySQLMySQL瞬间就会扛不住。解决方式是加空值缓存——即使推荐结果为空也把空结果缓存1分钟防止穿透。另外接口层面用布隆过滤器做用户ID有效性校验也是一道防线。缓存雪崩的场景推荐定时任务在每天零点统一计算结果写入Redis时设置了完全一样的过期时间那么所有缓存在同一秒到期同时回源MySQL数据库连接池直接被打满。解决方式很粗暴但有效缓存过期时间引入随机因子比如基础10分钟再随机加1-5分钟。我后来实测这个随机化之后缓存批量失效的情况基本消失了。6.3 数据稀疏导致的推荐质量差算法调参与数据增强还有一类问题是推荐结果“不聪明”。用户行为数据少评分矩阵稀疏度高达95%以上协同过滤算法会退化成“热门推荐”或“随机推荐”用户感知不到个性化。面对这种情况我用了两个策略。第一降低冷启动判定阈值。默认“有3条行为才算老用户”实际数据分析后发现跳蚤市场大部分用户的行为记录都在5条以下如果把阈值设为5覆盖的用户比例太窄。降为2条之后能够命中协同过滤的用户覆盖率高了很多。第二引入用户画像辅助。在协同过滤结果基础上叠加用户偏好分类——用户收藏最多的商品品类在推荐列表中按比例提升该品类的权重。这个策略虽然不完全属于协同过滤的范畴但和协同过滤结合后推荐列表的点击率提升是很明显的。下面把我踩过的坑整理成速查表方便你直接对照排查问题现象可能原因解决方案推荐任务耗时过长未做共现商品对筛选增加“至少被2个用户共同行为”过滤推荐结果几乎全是热门商品评分矩阵太稀疏降低冷启动阈值增加用户画像辅助用户刷新接口很慢Redis缓存未命中检查缓存Key的拼接格式是否一致用户反馈“推荐的都是看过的”未在算法中过滤已交互商品在候选集生成阶段排除interactedItems定时任务执行了但推荐没更新Scheduled被阻塞配置独立的定时线程池商品下架后仍在推荐列表推荐结果表未同步状态推荐查询时关联t_product.status过滤新商品没有曝光机会冷启动未处理新商品增加“最新发布”推荐位6.4 Jackson序列化和Long型精度丢失问题最后分享一个所有Java后端都会踩的经典坑当推荐结果中的商品ID数据库里是bigint类型大于Java的Long最大值边界转成JSON传给前端时JavaScript的Number类型会丢失精度。跳蚤市场的商品ID如果用了雪花算法生成19位ID传给前端后最后几位数字会变成0导致用户点击商品详情时ID错误、页面报404。解决方案有两个二选一即可。第一种是把实体类的id字段类型改成String只做展示不参与运算。第二种是在Jackson配置中注册ToStringSerializer序列化时把Long自动转成字符串。我用的第二种因为改动侵入性最小Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(Long.TYPE, ToStringSerializer.instance); }; } }这一行配置解决了从前端传参到后端查询的整个链路精度问题。这种坑用一句话总结就是后端交付的不只是接口而是前后端都能正确协作的数据契约。7. 一些实操心得与扩展建议7.1 从零到一跑通项目的建议顺序如果你正在做类似的推荐系统项目我的建议是按照下面这个顺序推进能少走很多弯路第一步先把Spring Boot的基础框架搭好用假数据写死一个推荐结果接口把前后端的数据链路跑通。第二步实现数据采集模块把浏览、收藏这些行为记录到数据库。第三步实现算法模块先用小数据集几百条行为记录跑通协同过滤流程。第四步写定时任务把离线计算的结果同步到Redis和推荐结果表。第五步接入真实数据观察推荐效果做参数调优。不要一上来就埋头写算法也不要一上来就搭复杂架构。先把一条最简单的主链路跑通再逐步丰富细节这个节奏是最稳的。7.2 后续扩展方向的思考如果你想把项目做深做远有几个很自然的扩展方向。算法层面可以尝试把协同过滤和内容推荐融合做混合推荐——用协同过滤捕捉行为模式用内容推荐补充冷启动和新商品曝光能力。性能层面如果用户量级到百万以上可以把离线计算迁移到Spark或Flink上用分布式计算框架替代单机算法。工程层面还可以加上A/B测试机制用实验数据验证不同算法策略的效果让推荐系统的迭代有数据依据而不是拍脑袋。最后说一点我的真实体会推荐系统最难的其实不是算法本身而是“数据质量”和“业务理解”这两件事。协同过滤算法的原理一天就能搞懂但把行为数据采集准确、把业务规则融入推荐流程、把冷启动和降级策略做到位这些才是项目真正的价值所在。尤其是跳蚤市场这个场景它的小众和杂糅属性恰恰给了做“小而美”推荐系统一个非常合适的切入口希望这篇实战总结能给你带来一些踏实的参考。