Huigr王1. 项目概述：基于用户的协同过滤购物系统
这个购物推荐系统采用了经典的协同过滤算法，但我们在实现过程中做了大量工程优化。不同于传统的基于内容的推荐，协同过滤最大的优势在于能够发现用户潜在的兴趣偏好——即使两个商品属性完全不同，只要购买它们的用户群体高度重合，系统就会建立这种"物以类聚"的关联关系。
举个例子，在我们的测试数据中，篮球和运动饮料经常被同一批用户购买，虽然它们分属体育用品和食品类别，但系统会自动将它们关联推荐。这种"啤酒与尿布"式的关联规则发现，正是协同过滤的魅力所在。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术架构解析
2.1 整体技术栈选择
我们采用SpringBoot+MyBatis的经典组合，主要基于以下考量：
- SpringBoot的自动配置特性快速搭建RESTful API
- MyBatis的动态SQL能力适合处理复杂的用户行为查询
- JSP作为视图层技术，便于快速渲染个性化推荐结果
- MySQL存储用户行为数据，利用其事务特性保证数据一致性
- Redis缓存用户相似度矩阵，降低实时计算压力
技术选型心得：初期考虑过使用Spark处理大规模数据，但实测发现当用户行为数据在100万条以下时，单机版的SpringBoot+Redis方案完全够用，且运维成本更低。
2.2 核心数据模型设计
用户行为表是系统的核心，其设计直接影响推荐效果：
sql复制CREATE TABLE user_behavior (
user_id INT NOT NULL,
item_id INT NOT NULL,
behavior_type TINYINT COMMENT '1浏览 2加购 3购买',
timestamp BIGINT,
PRIMARY KEY (user_id, item_id),
INDEX idx_item (item_id),
INDEX idx_user_behavior (user_id, behavior_type)
);
这个设计有几个关键点：
- 采用(user_id, item_id)联合主键，避免重复行为记录
- 为item_id单独建索引，加速"喜欢该商品的人也喜欢"查询
- 添加user_id+behavior_type的联合索引，优化用户行为分析
3. 核心算法实现
3.1 用户相似度计算
改进版余弦相似度算法的Java实现：
java复制public Map<Integer, Double> calculateUserSimilarity(int targetUserId) {
// 获取除目标用户外的所有用户
List<UserBehavior> allUsers = behaviorMapper.getAllUsersExcept(targetUserId);
// 构建用户-物品矩阵
Map<Integer, List<Integer>> userItemMap = new HashMap<>();
allUsers.forEach(user -> {
List<Integer> purchasedItems = behaviorMapper.getPurchasedItems(user.getUserId());
userItemMap.put(user.getUserId(), purchasedItems);
});
// 计算相似度
Map<Integer, Double> similarityScores = new HashMap<>();
List<Integer> targetItems = behaviorMapper.getPurchasedItems(targetUserId);
userItemMap.forEach((otherUserId, otherItems) -> {
// 使用HashSet求交集，时间复杂度O(min(m,n))
Set<Integer> intersection = new HashSet<>(targetItems);
intersection.retainAll(otherItems);
// 归一化余弦相似度计算
double cosine = intersection.size() /
Math.sqrt(targetItems.size() * otherItems.size());
similarityScores.put(otherUserId, cosine);
});
// 按相似度降序排序
return similarityScores.entrySet().stream()
.sorted(Map.Entry.comparingByValue(Comparator.reverseOrder()))
.collect(Collectors.toMap(
Map.Entry::getKey,
Map.Entry::getValue,
(oldValue, newValue) -> oldValue,
LinkedHashMap::new
));
}
算法优化点：
- 使用HashSet的retainAll方法替代双层循环，将交集计算复杂度从O(n²)降到O(n)
- 对稀疏向量进行长度归一化，避免活跃用户主导推荐结果
- 采用Java8 Stream API进行并行排序，提升大数据量下的处理效率
3.2 混合推荐策略
我们采用预计算+实时更新的混合策略：
java复制@Scheduled(cron = "0 0 3 * * ?") // 每天凌晨3点全量更新
public void precomputeSimilarUsers() {
userRepository.findAll().forEach(user -> {
Map<Integer, Double> similarities = calculateUserSimilarity(user.getId());
// 存储到Redis，设置24小时过期
redisTemplate.opsForHash().putAll(
"similarity:"+user.getId(),
similarities
);
redisTemplate.expire("similarity:"+user.getId(), 24, TimeUnit.HOURS);
});
}
// 实时更新接口
@PostMapping("/behavior")
public void recordUserBehavior(@RequestBody UserBehavior behavior) {
// 记录用户行为
behaviorMapper.insert(behavior);
// 实时更新相似用户(异步处理)
executorService.execute(() -> {
Map<Integer, Double> updatedSimilarities =
calculateUserSimilarity(behavior.getUserId());
redisTemplate.opsForHash().putAll(
"similarity:"+behavior.getUserId(),
updatedSimilarities
);
});
}
这种设计实现了：
- 每日全量更新保证数据完整性
- 实时增量更新确保新行为快速影响推荐结果
- Redis缓存避免频繁计算，设置合理过期时间防止内存泄漏
4. 工程实践与优化
4.1 性能优化方案
当用户行为数据达到10万级别时，我们遇到了以下性能瓶颈及解决方案：
-
MySQL查询优化：
- 将
IN语句改为临时表JOIN，避免索引失效 - 对高频查询添加覆盖索引
- 使用批处理减少数据库往返次数
- 将
-
缓存策略改进：
- 相似度矩阵采用Redis Hash结构存储
- 实现LRU淘汰策略，内存占用降低40%
- 对热门商品实施本地缓存，响应时间从200ms降至50ms
-
前端渲染优化：
- JSP页面实现动静分离
- 商品图片走CDN加速
- 推荐结果异步加载，首屏时间缩短30%
4.2 推荐效果评估
我们采用A/B测试验证推荐效果：
| 指标 | 传统推荐 | 协同过滤 | 提升幅度 |
|---|---|---|---|
| 点击率(CTR) | 2.1% | 5.7% | 171% |
| 转化率 | 0.8% | 2.3% | 188% |
| 平均订单金额 | ¥158 | ¥203 | 28% |
关键发现：
- 长尾商品曝光量增加3倍
- 用户停留时间延长2分钟
- 复购率提升15个百分点
5. 常见问题与解决方案
5.1 冷启动问题
症状：新用户或新商品缺乏行为数据，难以产生有效推荐
解决方案：
- 新用户：采用热门商品+随机推荐混合策略
- 新商品：基于内容相似度进行初始推荐
- 实施"探索-利用"机制，保留5%流量尝试新组合
5.2 数据稀疏性问题
症状：用户-物品矩阵过于稀疏，相似度计算不准确
优化措施：
- 引入行为权重：购买=3，加购=2，浏览=1
- 使用Jaccard系数补充余弦相似度
- 对低频用户进行聚类处理
5.3 实时性挑战
症状：用户最新行为无法及时影响推荐结果
应对方案：
- 构建双缓存层：Redis+本地缓存
- 实现分级更新策略：
- 关键行为（购买）实时触发更新
- 次要行为（浏览）延迟批量处理
- 采用消息队列削峰填谷
6. 系统部署与监控
6.1 生产环境配置
我们的线上部署方案：
- 2台4核8G的ECS实例运行应用
- Redis集群（3节点）处理缓存
- MySQL主从架构保障数据安全
- ELK日志收集系统监控运行状态
关键JVM参数：
bash复制-Xms4g -Xmx4g -XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=35
6.2 监控指标
建立了完善的监控体系跟踪：
-
性能指标：
- 推荐接口响应时间(P99<300ms)
- 缓存命中率(>90%)
- 数据库QPS(<2000)
-
业务指标：
- 推荐商品点击率
- 推荐转化漏斗分析
- 用户兴趣漂移检测
-
异常预警：
- 相似度计算超时
- 缓存穿透风险
- 数据同步延迟
7. 扩展与演进方向
当前系统已支持日均100万次推荐请求，后续规划：
-
算法层面：
- 引入图神经网络捕捉高阶关系
- 尝试多目标优化（点击率+转化率+多样性）
- 加入时间衰减因子处理兴趣漂移
-
架构层面：
- 实现推荐引擎微服务化
- 接入Flink实时计算管道
- 构建特征仓库统一管理用户画像
-
产品层面：
- 开发推荐理由生成功能
- 增加"不感兴趣"反馈机制
- 实现场景化推荐（节日/季节专题）
这个项目给我的最大启示是：推荐系统不是算法越复杂越好，关键在于找到业务需求与技术实现的平衡点。我们的方案虽然没有使用最前沿的深度学习模型，但通过扎实的工程优化和合理的产品设计，最终取得了超出预期的业务效果。