DA EE1. 项目背景与核心需求
作为一个长期泡在豆瓣和IMDb的老影迷，我经常遇到一个尴尬：想给朋友推荐电影时，发现豆瓣评分和IMDb评分差距巨大，而两个平台的评论风格也截然不同。这让我萌生了开发一个整合型书影音评分平台的想法——既能保留专业影评人的深度分析，又能容纳普通观众的直观感受。
这个Spring Boot书影音评分网站的核心需求可以拆解为三个维度：
-
多媒介整合：支持书籍、电影、音乐三种媒介类型的评分与评论，每种类型有独立的评分维度和展示界面。比如电影需要"剧情""演技""特效"等细分项，而书籍则更关注"文笔""思想性""翻译质量"。
-
混合评分系统：
- 专业评分（权重30%）：邀请行业KOL、媒体人入驻
- 大众评分（权重70%）：普通用户评分
- 动态加权算法：新上映作品大众评分权重更高，经典作品专业评分权重提升
-
社交化功能：
- 个人收藏夹与年度榜单
- "同好匹配"算法：根据评分相似度推荐好友
- 争议作品预警系统：当评分标准差超过阈值时触发
提示：毕设项目选择这个方向时，建议先聚焦核心评分功能，社交模块可作为二期开发。我的毕业答辩就因为过早引入推荐算法导致DEMO不稳定，最后不得不临时砍掉这部分演示。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术架构设计
2.1 为什么选择Spring Boot
在技术选型阶段，我对比过三种方案：
- 传统SSM框架：配置复杂，依赖注入需要大量XML
- Play Framework：异步性能好但国内生态弱
- Spring Boot：约定优于配置，起步依赖简化构建
最终选择Spring Boot 2.7.x版本（现在建议用3.0+）基于以下考量：
- 内嵌Tomcat：简化部署，
mvn spring-boot:run即可启动 - Starter依赖：通过
spring-boot-starter-data-jpa等组件快速集成 - Actuator监控：毕设演示时可以用
/actuator/health展示系统状态 - Profile机制：用
application-dev.yml和application-prod.yml区分环境配置
2.2 分层架构实现
项目采用经典三层架构，但做了些针对性优化：
java复制com.example.mediaplatform
├── config # 自定义配置类
│ ├── RedisConfig.java # 缓存配置
│ └── SecurityConfig.java # 安全配置
├── controller # 表现层
│ ├── api # RESTful API
│ └── web # 传统MVC
├── service # 业务逻辑层
│ ├── impl # 实现类
│ └── task # 定时任务
├── repository # 数据访问层
│ ├── custom # 自定义查询
│ └── entity # JPA实体
└── exception # 全局异常处理
特别说明几个关键设计：
- 双Controller设计：
api包用于前端对接，web包保留Thymeleaf模板引擎支持，方便答辩时直接演示 - Repository扩展：通过
@Query注解实现复杂查询，如：java复制@Query("SELECT m FROM Movie m WHERE m.releaseDate BETWEEN :start AND :end ORDER BY m.rating DESC") List<Movie> findTopMoviesByPeriod(@Param("start") LocalDate start, @Param("end") LocalDate end); - 异常统一处理：使用
@ControllerAdvice捕获MethodArgumentNotValidException等异常，返回标准JSON格式
3. 核心功能实现细节
3.1 动态评分算法
评分计算是系统的核心难点，需要考虑：
- 时间衰减：新评分权重高于旧评分
- 用户权重：活跃用户 vs 新用户
- 反作弊：检测刷分行为
最终实现的评分服务类关键代码：
java复制public class RatingService {
// 时间衰减系数（天）
private static final double DECAY_FACTOR = 0.995;
public double calculateCompositeScore(Media media) {
List<Rating> ratings = ratingRepository.findByMedia(media);
double professionalScore = media.getProfessionalRating();
double publicScore = ratings.stream()
.mapToDouble(r -> {
// 计算时间衰减
long days = ChronoUnit.DAYS.between(
r.getCreateTime(),
LocalDate.now()
);
double timeWeight = Math.pow(DECAY_FACTOR, days);
// 计算用户权重
double userWeight = calculateUserWeight(r.getUser());
return r.getScore() * timeWeight * userWeight;
})
.average()
.orElse(0);
return professionalScore * 0.3 + publicScore * 0.7;
}
private double calculateUserWeight(User user) {
// 根据用户活跃度、注册时长等计算权重
// 实现略...
}
}
3.2 缓存策略优化
使用Redis缓存热门作品数据时，遇到经典的缓存穿透问题——当查询不存在的作品ID时，会直接击穿缓存访问数据库。解决方案：
- 布隆过滤器：在Redis中维护已存在作品的Bloom Filter
- 空值缓存：对查询为null的结果也缓存5分钟
- 互斥锁：使用Redisson的
RLock防止缓存重建时的并发问题
配置示例：
yaml复制spring:
redis:
host: localhost
port: 6379
cache:
type: redis
redis:
time-to-live: 1h # 常规缓存1小时
cache-null-values: true
key-prefix: 'media:' # 避免key冲突
4. 典型问题与解决方案
4.1 N+1查询问题
在展示作品列表时，控制台出现大量SQL查询。这是典型的JPA N+1问题——查询1次作品列表，然后对每个作品又查询1次关联的评分数据。
解决方案对比：
| 方案 | 实现方式 | 优点 | 缺点 |
|---|---|---|---|
| @EntityGraph | 在Repository方法添加注解 | 配置简单 | 复杂关联时不够灵活 |
| JOIN FETCH | 在JPQL中显式指定 | 精确控制 | 需要写自定义查询 |
| Batch Size | 在实体类添加@BatchSize | 全局生效 | 可能加载不必要数据 |
最终选择混合方案：
java复制@EntityGraph(attributePaths = {"ratings"})
@Query("SELECT m FROM Movie m WHERE m.status = 'ONLINE'")
Page<Movie> findOnlineMovies(Pageable pageable);
4.2 并发评分冲突
当多个用户同时给同一作品评分时，可能出现总分计算错误。通过乐观锁解决：
- 在Media实体添加版本号字段
java复制@Version
private Integer version;
- 在Service层添加重试机制
java复制@Retryable(value = ObjectOptimisticLockingFailureException.class,
maxAttempts = 3)
public void addRating(Long mediaId, RatingDTO dto) {
// 业务逻辑
}
5. 前端实现技巧
虽然项目后端是重点，但毕设演示时前端效果也很重要。推荐几个实用技巧：
- 模版选择：使用AdminLTE 3开源模板快速搭建后台，配合Vue.js实现前后端分离
- 图表展示：通过ECharts实现评分趋势图，关键配置：
javascript复制option = { xAxis: { type: 'category', data: ['剧情','演技','特效'] }, yAxis: { type: 'value', max: 10 }, series: [{ type: 'radar', data: [{ value: [8.2, 9.1, 7.5], name: '流浪地球2' }] }] }; - 演示优化：在
data.sql中预置测试数据，确保答辩时展示效果稳定
6. 项目部署与监控
6.1 多环境配置
使用Spring Profiles管理不同环境：
yaml复制# application-dev.yml
server:
port: 8080
spring:
datasource:
url: jdbc:h2:mem:testdb
username: sa
password:
jpa:
hibernate.ddl-auto: update
show-sql: true
# application-prod.yml
spring:
datasource:
url: jdbc:mysql://localhost:3306/media?useSSL=false
username: root
password: 123456
jpa:
hibernate.ddl-auto: validate
启动时指定profile：
bash复制java -jar media-platform.jar --spring.profiles.active=prod
6.2 监控方案
-
基础监控：通过Spring Boot Actuator暴露端点
yaml复制management: endpoints: web: exposure: include: health,info,metrics -
日志收集：使用Logback+ELK方案
xml复制<!-- logback-spring.xml --> <appender name="ELK" class="net.logstash.logback.appender.LogstashTcpSocketAppender"> <destination>127.0.0.1:5000</destination> <encoder class="net.logstash.logback.encoder.LogstashEncoder"/> </appender> -
异常报警：通过Spring Boot Admin实时监控
7. 毕设答辩技巧
根据我参加多次答辩的经验，分享几个关键点：
- 演示数据准备：提前录制演示视频作为备用方案，防止现场网络问题
- 技术亮点提炼：重点讲解动态评分算法和缓存策略，这是区分普通CMS系统的关键
- 问答准备：常见问题包括：
- 如何防止刷分？(回答：用户权重算法+行为分析)
- 为什么不用现成框架？(回答：学习目的+定制需求)
- 性能指标如何？(回答：JMeter测试结果，支持500QPS)
- 代码展示：用GitHub的Insights功能展示代码提交历史，体现开发过程
项目源码结构建议按功能模块组织提交，避免一次性提交大量代码。我的个人仓库结构供参考：
code复制├── docs # 文档
│ ├── 需求规格说明书.md
│ └── 数据库设计.pdf
├── src
│ ├── main
│ └── test # 包含JMeter测试脚本
└── script # 部署脚本
├── docker-compose.yml
└── init_db.sql