SSM协同过滤旅游平台毕设：从相似度计算到推荐系统落地

简介一套基于SSM框架与协同过滤算法实现的在线通用旅游平台毕业设计项目面向计算机相关专业毕业生及Java入门至进阶学习者可作为毕设、课程设计或期末大作业使用。项目包含前端、后端与MySQL完整源码经严格调试可运行并附数据库脚本、开发说明文档、论文、演示视频及代码注释。系统功能覆盖景点推荐管理、精选路线管理、用户信息管理、系统管理四大模块其中景点推荐支持信息增删改查精选路线可依据游客需求推荐合适出行路线管理员可维护公告、简介、留言与站内新闻。资源包大小约106.17MB主要文件类型包括java源码、sql脚本、word文档、mp4演示视频等结构清晰便于直接部署学习。目前已有109人学习下载适合需要完整可运行项目参考并希望理解SSM整合与协同过滤应用逻辑的读者。1. 从毕设选题的痛点说起SSM协同过滤旅游平台到底是什么每到毕业设计的高峰期做Java的同学都会在同样的路口打转旅游网站、商城系统、预约平台这类题目铺天盖地绝大多数是SSM写后台管理加一张MySQL表。这套基于SSM的协同过滤在线通用旅游平台属于java毕业设计里比较少见带着算法亮点的选题——它不只是景点的增删改查而是把用户的收藏行为和评分记录变成推荐系统的输入让“热门景点”和“猜你喜欢”真正区分开。项目把前端页面、后端Java源码、MySQL完整脚本、开发说明文档和演示视频都打成了一个zip包课程设计、期末大作业、毕设答辩三个场景都能直接用。需要说明白的是这个项目解决的核心问题不是“做一个旅游网站”而是“在旅游网站上把推荐做出来且能讲清楚原理”。2. SSM架构与数据库表设计协同过滤的数据从哪来2.1 三层架构的请求链路Controller、Service、Mapper怎么分工SSM由Spring、Spring MVC、MyBatis三块拼成项目里的大多数业务逻辑都遵循“控制器接请求、服务层算业务、Mapper查数据库”的单向链路。以景点推荐管理模块为例用户在页面点“添加景点”浏览器把POST请求送到ControllerController调Service里的方法做参数校验Service再调Mapper接口操作MySQL表结果一层层返回到页面。协同过滤推荐算法也挂在这条链路上只是Service层不只查库还要先计算用户之间的相似度。从实际调试的角度看SSM最需要先理解的是Spring容器负责管理Service和Mapper的实例Spring MVC负责把URL映射到Controller方法MyBatis负责把Mapper接口和XML里的SQL绑定起来。很多第一次跑SSM项目的人翻车是因为没分清这三层各自的配置文件spring-mvc.xml里配控制器扫描和视图解析器applicationContext.xml里配数据源和Service扫描mybatis-config.xml里配别名和Mapper映射。项目拿到手后先别急着改代码按这三个文件把依赖关系捋一遍后面排查问题会快很多。2.2 数据库表如何支撑协同过滤这个项目的表设计并不复杂但有几张表是推荐算法的“原料库”。用户信息表负责存放注册用户的基础资料景点表存放名称、位置、价格、评分和分类信息精选路线表把多个景点串成一条路线还有一张收藏表和一张评分表专门记录用户对景点的行为。协同过滤需要的数据就是“哪个用户对哪个景点有过行为”所以收藏表和评分表才是推荐模块真正依赖的核心。用标准的建表SQL来看一下收藏表的结构CREATE TABLE t_favorite ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) DEFAULT NULL, scenic_id int(11) DEFAULT NULL, create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_scenic (scenic_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段SQL里最值得关注的是两个索引字段user_id和scenic_id。推荐算法第一步是构建“用户对景点”的矩阵本质上就是反复按用户ID分组查收藏记录没有这两个索引数据量过百条后查询会明显变慢。create_time字段虽然不参与相似度计算但在二次开发时可以做时间衰减后面第5章会提到。景点表的字段设计也直接决定了推荐结果的美观度CREATE TABLE t_scenic ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL, location varchar(255) DEFAULT NULL, price decimal(10,2) DEFAULT 0.00, score decimal(3,2) DEFAULT 5.00, category varchar(50) DEFAULT NULL, cover varchar(255) DEFAULT NULL, status int(1) DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;category字段在做“同类目补充推荐”时很有用price字段可以用来做价格区间的兜底推荐。一个常见的做法是当协同过滤因为数据稀疏算不出结果时先按category和price相近的景点补位避免推荐区域空白这个策略在答辩时也能讲成业务上的降级方案。如果用表格来归纳表与推荐算法的关系会更直观表名核心字段对推荐算法的作用t_userid、username、nickname提供用户维度的唯一标识t_scenicid、name、category、price、score构成推荐候选集与展示信息t_favoriteuser_id、scenic_id隐性评分数据点击收藏视为1分t_ratinguser_id、scenic_id、score显式评分数据用户直接打分t_routeid、route_name、scenic_ids路线粒度的高级推荐可做扩展这里想强调一个容易被忽略的点数据库里的score字段是景点自身的平均评分和协同过滤里的用户评分是两个概念。景点平均评分只能做排序兜底协同过滤算的是“用户之间的口味相似度”。如果开发说明文档里没有单独建评分表也可以用收藏表加评论表的组合替代只是代码里要把预处理逻辑写清楚我一般会在Service层先统一封装成List结构再喂给算法。3. 协同过滤推荐核心相似度计算与推荐列表的完整实现3.1 基于用户的协同过滤算法如何落到代码上基于用户的协同过滤思路用一句话概括就是找和你口味相似的人看看他们喜欢什么你还没看过的东西。具体到旅游平台就是先把用户收藏和评分的景点整理成一张稀疏矩阵然后计算目标用户与其它用户的余弦相似度选出最像的K个邻居再拿邻居的偏好加权预测目标用户对未访问景点的兴趣分最后按分数取TopN返回。下面这个类是核心算法的精简实现实际项目中可以直接把这段逻辑放进Service层public class UserBasedCF { private MapInteger, MapInteger, Double userItemMatrix new HashMap(); private SetInteger allScenicIds new HashSet(); public void loadData(ListRateRecord records) { for (RateRecord r : records) { userItemMatrix .computeIfAbsent(r.getUserId(), k - new HashMap()) .put(r.getScenicId(), r.getScore()); allScenicIds.add(r.getScenicId()); } } public ListInteger recommend(int userId, int topN) { MapInteger, Double selfRatings userItemMatrix.get(userId); if (selfRatings null || selfRatings.isEmpty()) { return Collections.emptyList(); } // 第一步计算目标用户与其他用户的余弦相似度 MapInteger, Double similarityMap new HashMap(); for (Map.EntryInteger, MapInteger, Double entry : userItemMatrix.entrySet()) { if (entry.getKey().equals(userId)) continue; double sim cosineSimilarity(selfRatings, entry.getValue()); if (sim 0) similarityMap.put(entry.getKey(), sim); } // 第二步选出相似度最高的K个邻居K取5 ListMap.EntryInteger, Double sortedUsers new ArrayList(similarityMap.entrySet()); sortedUsers.sort((a, b) - Double.compare(b.getValue(), a.getValue())); int k Math.min(5, sortedUsers.size()); ListInteger neighbors new ArrayList(); for (int i 0; i k; i) { neighbors.add(sortedUsers.get(i).getKey()); } // 第三步加权汇总邻居的评分并归一化 MapInteger, Double scoreMap new HashMap(); MapInteger, Double weightMap new HashMap(); for (Integer neighbor : neighbors) { double sim similarityMap.get(neighbor); MapInteger, Double neighborRatings userItemMatrix.get(neighbor); for (Map.EntryInteger, Double item : neighborRatings.entrySet()) { if (selfRatings.containsKey(item.getKey())) continue; scoreMap.merge(item.getKey(), sim * item.getValue(), Double::sum); weightMap.merge(item.getKey(), sim, Double::sum); } } // 第四步按加权平均分排序取前topN个景点ID ListScenicScore list new ArrayList(); for (Map.EntryInteger, Double e : scoreMap.entrySet()) { double weight weightMap.getOrDefault(e.getKey(), 1.0); list.add(new ScenicScore(e.getKey(), e.getValue() / weight)); } list.sort((a, b) - Double.compare(b.getScore(), a.getScore())); return list.stream() .limit(Math.min(topN, list.size())) .map(ScenicScore::getScenicId) .collect(Collectors.toList()); } private double cosineSimilarity(MapInteger, Double a, MapInteger, Double b) { // 只取两个用户都打过分的景点取交集计算余弦值 double dot 0, normA 0, normB 0; for (Map.EntryInteger, Double e : a.entrySet()) { normA e.getValue() * e.getValue(); Double other b.get(e.getKey()); if (other ! null) dot e.getValue() * other; } for (Double value : b.values()) { normB value * value; } if (normA 0 || normB 0) return 0; return dot / (Math.sqrt(normA) * Math.sqrt(normB)); } }这里的关键逻辑有四处。第一处是loadData方法把数据库里的原始记录转成“用户ID到景点评分映射”的嵌套结构这一步决定了后续计算只能看到二维矩阵看不到其它冗余字段既减少内存占用也方便计算。第二处是cosineSimilarity方法只取两个用户共同评分过的景点做点积如果交集为空相似度直接归零这是一个必要的保护条件。第三处是K值的选择代码里先用5做固定值数据量大的项目可以改成构造方法传参方便调优。第四处是加权平均的归一化处理如果不除以weightMap里的相似度总和评分高的邻居会主导结果推荐会偏向单一用户。3.2 Service层与Controller层如何把推荐结果拼装成页面数据算法算出的只是景点ID的List页面真正需要的是景点名称、图片、价格这些完整信息所以Service层要做一次“算法结果转业务数据”的桥接。下面这段代码是推荐Service的常见写法Service public class RecommendService { Autowired private FavoriteMapper favoriteMapper; Autowired private ScenicMapper scenicMapper; public ListScenicVO recommendScenic(Integer userId, Integer topN) { // 1. 拉取全量用户行为数据构建协同过滤输入 ListRateRecord records favoriteMapper.selectAllForRecommend(); if (records.isEmpty()) { return scenicMapper.selectHotList(topN); } UserBasedCF cf new UserBasedCF(); cf.loadData(records); ListInteger scenicIds cf.recommend(userId, topN); // 2. 冷启动兜底用户无行为或算法结果为空时按热度推荐 if (scenicIds.isEmpty()) { return scenicMapper.selectHotList(topN); } // 3. 按算法结果顺序返回景点详情 return scenicMapper.selectByIdsOrdered(scenicIds); } }这段Service代码要注意两点。第一点favoriteMapper.selectAllForRecommend()返回的是所有用户的收藏记录如果线上数据量很大这种全量查询需要改成按最近时间段过滤比如只取最近90天的行为既降低内存压力也符合“近期偏好”的业务直觉。第二点selectByIdsOrdered这个方法在MyBatis里不能用普通的IN查询因为IN查出来的顺序不保证和传入的ID顺序一致需要用foreach循环配合CASE WHEN或者直接在Java层按顺序组装否则推荐列表的顺序会被数据库打乱。Controller层就相对轻量主要是从Session里拿当前登录用户然后调用ServiceController RequestMapping(/scenic) public class ScenicController { Autowired private RecommendService recommendService; RequestMapping(/recommend) ResponseBody public Result recommend(HttpSession session) { User user (User) session.getAttribute(loginUser); int topN 6; if (user null) { return Result.success(recommendService.recommendScenic(null, topN)); } return Result.success(recommendService.recommendScenic(user.getId(), topN)); } }这里的topN6是给首页“猜你喜欢”区域准备的6个卡片刚好排满两行。游客身份没有用户IDService层就会走热度兜底逻辑这也解释了为什么未登录状态下看到的推荐区域和登录后的内容不同——不是Bug是设计如此。答辩时如果能把这个细节讲出来评委通常会认可你对业务场景的理解。4. 部署运行与踩坑排查从Maven构建到Tomcat上线最常见的四个问题4.1 部署运行的基本步骤与参数检查拿到项目后正确顺序是先初始化数据库再启动后端最后打开浏览器验证前端页面。数据库脚本直接用MySQL命令行导入但要注意导入前建好一个空的数据库实例否则表会散落在默认库里。后端是标准的Maven war包结构通过IDEA打开后在右侧Maven面板里执行clean和package命令打好的war包放到Tomcat的webapps目录下启动Tomcat后用浏览器访问首页。如果习惯用命令行操作构建和部署的命令大致是这样的# 第一步初始化数据库travel_platform.sql是项目附带的脚本 mysql -uroot -p travel_platform.sql # 第二步跳过测试打包避免JUnit测试干扰部署 mvn clean package -DskipTests # 第三步把war包复制到Tomcat的webapps目录 cp target/travel-platform.war /path/to/tomcat/webapps/ # 第四步启动Tomcat并持续观察日志 /path/to/tomcat/bin/startup.sh tail -f /path/to/tomcat/logs/catalina.out这里最需要理解的是war包名直接决定访问路径。如果travel-platform.war被复制到webapps下访问地址就是localhost:8080/travel-platform如果改成ROOT.war则可以直接用localhost:8080访问。不少同学打开页面404大概率是忘了这层关系。另外catalina.out日志是排错的第一现场Tomcat启动时如果有Bean创建异常、数据源连接失败StackOverflow都会打印在这个文件里不要只看IDEA控制台。4.2 启动时直接报数据库连接失败现象Tomcat启动过程中日志里出现“Communications link failure”或者“Access denied for user”项目首页打不开后台控制台一片红色异常。原因最常见的是jdbc.properties文件里的数据库地址、用户名或密码与本地MySQL环境不一致也可能是MySQL服务根本没启动。其次是JDBC驱动版本和MySQL版本不匹配比如数据库升级到8.0以上但驱动还停留在5.x会报SSL连接或者CLIENT_PLUGIN_AUTH错误。解决先确认MySQL服务已启动再用命令行手动登录一次验证账号密码。接着检查项目里jdbc.properties的配置重点看url要写成jdbc:mysql://localhost:3306/数据库名?useUnicodetruecharacterEncodingUTF-8如果本地MySQL是8.0以上驱动和URL也要按8.0的写法调整。联网搜索时经常看到有人把“validateQuery”或者“testOnBorrow”的配置加进去这套项目里不需要但排查数据库连接时可以先去掉连接池的复杂参数用最简配置定位问题。4.3 页面能登录但跳转到空白页或404现象登录功能正常数据库也能查到用户但登录成功后跳转到一个空页面或者页面的CSS、JS、图片全部变形。原因根因是Spring MVC的DispatcherServlet拦截了静态资源请求。配置了“/”作为url-pattern后所有请求都会进Spring MVC如果spring-mvc.xml没有声明静态资源放行规则浏览器请求CSS、JS时就会走到控制器映射里找不到处理器结果是404。另一个常见原因是视图解析器的前缀后缀配置不对返回的JSP路径拼出来是/WEB-INF/views/xxx.jsp但实际页面不在这个目录下。解决在spring-mvc.xml里补充静态资源映射配置下面这段是标准写法mvc:resources mapping/static/** location/static// mvc:annotation-driven/如果项目里静态资源放在webapp根目录的static文件夹下这段配置就能让浏览器正常拿到CSS和JS。JSP路径的问题则要检查视图解析器的prefix和suffix属性例如bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views// property namesuffix value.jsp/ /bean这段配置说明Controller返回“scenic/list”时实际加载的是/WEB-INF/views/scenic/list.jsp。在排查过程中我一般会先在浏览器开发者工具里看Network面板如果HTML能加载但CSS返回404就是静态资源放行问题如果HTML本身都没出来再往视图解析器方向查。4.4 推荐列表一直为空或显示的景点不是推荐的现象看到“猜你喜欢”区域但里面要么是空白要么和热门景点排序完全一样没有个性化差别。原因协同过滤的冷启动和数据稀疏问题。新建的用户没有任何收藏和评分记录从用户-景点矩阵里找不到这个用户的行算法返回空列表。代码里虽然有热度兜底但如果兜底逻辑写成了“查到全部景点再按ID排序”推荐区域看起来就会像是随机景点而不是个性化结果。解决为了让演示效果好需要在库里模拟一部分用户行为数据。管理员账号注册后去收藏几个景点再换一个普通用户注册登录让两个用户之间有部分重叠的收藏记录。数据准备充分后推荐结果才会有明显差异。另外还要检查FavoriteMapper的selectAllForRecommend是否能查到数据这个简单SQL如果在窗口里能跑出结果问题就不在数据层。4.5 JSP页面中文乱码现象登录后页面上的用户名、景点名称、路线描述都是乱码但数据库里看数据正常。原因字符编码链路上有三处可能不一致。JSP页面本身不是UTF-8编码、MySQL连接的URL缺少characterEncoding参数、Tomcat的Connector没有设置URIEncoding。这三处只要有一处断了中文就会显示成“ç”或“??”。解决JSP文件开头加page指令MySQL的JDBC URL里带编码参数Tomcat的server.xml里给Connector增加URIEncodingUTF-8。这是Web开发里典型的编码三件套Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 URIEncodingUTF-8/排查顺序是先看JSP页面文件编码再看数据库脚本导入时的会话编码最后才是Tomcat连接器。很多情况下问题出在导入SQL脚本时用的是命令行Windows命令行默认GBK编码导入的UTF-8文本变成了乱码解决办法是用Navicat或者通过sql文件头加SET NAMES utf8mb4来强制指定。5. 答辩前二次验证与展示技巧让算法效果能讲出真实数据到了答辩前一周很多人还在反复跑页面截图但其实重点应该放在验证推荐效果和准备讲解逻辑上。验证方法不需要多复杂注册三个测试账号分别给它们制造不同的收藏偏好比如A账号都收藏山水类景点B账号都收藏古城类景点C账号同时收藏了山水类和一处古城。登录A账号看推荐列表里是否有C收藏的那处古城景点如果有说明相似用户成功传递了偏好如果没有说明算法中的相似度计算或者邻居选取有数据问题。这个小实验花不了半小时但能成为答辩现场最有说服力的证据。如果想让推荐效果更贴近真实业务我一般会做一个扩展改动给相似度加上时间衰减因子。具体做法是把收藏表的create_time变成权重系数近期收藏比长期收藏在计算时赋更高权重公式上就是在cosineSimilarity的点积部分乘一个衰减因子。这个改动不算大但答辩时可以讲成“考虑用户兴趣漂移的改进”是个低成本高收益的亮点。从代码讲解的技巧来说不要从Controller开始讲评委更想听到的是数据流登录取到用户ID行为表里拉出所有收藏记录拼成稀疏矩阵计算余弦相似度选TopK邻居加权平均得到TopN结果。这一串如果能在电脑上边翻代码边讲三分钟就能讲完随后留时间回答“为什么不优先看景点评分”这类追问。我的习惯是回答这类问题时强调评分是物品维度的静态属性协同过滤解决的是用户维度偏好匹配两者是不同层面的信号。至于路线推荐模块它是精选路线管理的一个延伸点。目前的实现更偏重管理员配置路线真正基于协同过滤做路线推荐需要把路线和景点的关系表加进来构建“用户-路线”矩阵。如果剩余时间充足把路线维度加进推荐列表里项目从“景点推荐”升级成“路线推荐”内容会更饱满。从那以后我每次拿到这类带算法的SSM项目都会强制走一遍“看配置文件、建库导数据、注册两个用户制造行为差异、再跑推荐页”的完整流程不再急着改界面样式。跑通只是第一步能把推荐结果和用户行为对上才算真正把项目吃透了。希望这份拆解能帮你在毕设答辩前少走弯路也欢迎你按这套流程去检验下载的资源包里每一个模块到底靠不靠得住。本文还有配套的精品资源点击获取