尧图网页设计 
简介这份资源是面向Java Web初学者与系统设计人员的动漫网站毕业设计文档基于JSP、HTML结合MyEclipse与Tomcat采用B/S结构搭建动漫信息视频网站帮助读者理解从需求分析到功能落地的完整开发流程。系统涵盖动漫类别管理、动漫信息管理、动漫上传下载、会员信息管理及动漫资讯管理并区分管理员与会员两套角色体系后台以MySQL存储数据兼顾安全性与数据完整性。压缩包内为1个docx文件约816KB即郑州大学毕业设计论文全文包含中英文摘要、绪论、需求分析、系统设计、关键代码实现与系统测试等章节目录结构完整可直接作为同类选题的写作模板与开发参考。目前已有71人学习适合需要完成课程设计或毕业设计、希望快速掌握JSP网站开发思路的读者借鉴。1. 从零搭一个动漫网站Java 后端到底要解决哪些真问题很多人第一次接到「基于 Java 的动漫网站设计与实现系统开发」这类题目脑子里第一反应是套一个 Spring Boot 脚手架把用户、视频、评论三张表一建接口一写就完事。真跑起来才发现动漫网站和普通内容站根本不是一回事一集 24 分钟的视频要分片、要防盗链、要记录播放进度番剧有季度、有更新日历、有「追番」这种强关系数据弹幕是高频写入还要按时间轴对齐。这些需求决定了后端不能只做增删改查得把并发、缓存、事务边界都想清楚。这篇笔记面向两类人一是正在做课程设计或毕业设计、需要一套能跑通且讲得清技术选型的开发者二是想用 Java 技术栈练手一个真实业务系统的后端工程师。我会按「数据模型怎么设计 → 核心接口怎么写 → 播放与弹幕怎么扛住并发 → 部署和踩坑」的顺序讲代码基于 Spring Boot MyBatis 的常见组合数据库用 MySQL缓存用 Redis。凡是涉及具体参数的地方我都会给出可改的数值和调整依据你照着复现能跑起来也能看懂每一步为什么这么做。2. 动漫网站的数据模型番剧、剧集、用户关系怎么拆表2.1 为什么不能把「动漫」和「剧集」塞进一张表新手最容易犯的错是建一张anime表字段里塞episode_count、video_url结果一部番有 12 集就得存 12 条几乎重复的记录更新封面时改 12 次。正确做法是按内容层级拆成三张核心表anime作品、episode剧集、video_source播放源。一部作品对应多条剧集一集剧集可能对应多个清晰度的播放源这是典型的一对多再一对多。拆表带来的直接好处是更新作品信息只动一行剧集可以单独控制上架下架播放源可以按清晰度、线路分别管理某个 CDN 挂了只切对应源。代价是查询时要 join但这个 join 有索引支撑成本可控。-- 作品表一部番剧的元信息 CREATE TABLE anime ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL COMMENT 作品名, cover_url VARCHAR(255) COMMENT 封面图, season_year INT COMMENT 放送年份, season_quarter TINYINT COMMENT 1-4 对应春夏秋冬, status TINYINT DEFAULT 0 COMMENT 0未开播 1连载中 2已完结, description TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_season (season_year, season_quarter) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 剧集表一集一行 CREATE TABLE episode ( id BIGINT PRIMARY KEY AUTO_INCREMENT, anime_id BIGINT NOT NULL, episode_no INT NOT NULL COMMENT 第几集, title VARCHAR(128), duration INT COMMENT 时长秒, publish_at DATETIME COMMENT 更新时间, UNIQUE KEY uk_anime_ep (anime_id, episode_no), INDEX idx_publish (publish_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 播放源表一集多线路多清晰度 CREATE TABLE video_source ( id BIGINT PRIMARY KEY AUTO_INCREMENT, episode_id BIGINT NOT NULL, quality VARCHAR(16) COMMENT 360p/720p/1080p, line_name VARCHAR(32) COMMENT 线路A/线路B, play_url VARCHAR(512) NOT NULL, INDEX idx_episode (episode_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;anime表上的idx_season索引是为「本季新番」列表页准备的按年份加季度过滤是最常见的查询。episode表的唯一键uk_anime_ep保证同一部番不会出现重复集号这个约束在批量导入时能挡掉脏数据。video_source不设唯一键因为同一集同一清晰度允许有多条备用线路。2.2 追番关系表与播放进度表的设计取舍「追番」本质是用户和作品的多对多关系但直接建user_anime_follow中间表还不够因为列表页要按追番时间倒序展示还要显示「看到第几集」。我的做法是把追番关系和播放进度合并到一张表CREATE TABLE user_follow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, anime_id BIGINT NOT NULL, last_episode_id BIGINT COMMENT 最后观看的剧集, last_position INT DEFAULT 0 COMMENT 播放进度秒, followed_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_anime (user_id, anime_id), INDEX idx_user_time (user_id, updated_at DESC) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;合并的理由是用户点「追番」和「继续观看」在业务上高度重合分开两张表会导致每次进个人中心要 join 两次。合并后idx_user_time直接支撑「我的追番」按最近观看排序。last_position记录秒数前端播放器每 15 秒上报一次后端做 upsert。注意updated_at用ON UPDATE CURRENT_TIMESTAMP自动维护但批量更新进度时如果值没变 MySQL 不会触发更新所以上报接口里要显式SET updated_at NOW()。2.3 用 MyBatis 写分页查询的常见写法列表页几乎都要分页MyBatis-Plus 的Page对象是最省事的方案但要注意 count 查询的性能。下面是一个按季度查番剧的分页方法public PageAnimeVO listBySeason(int year, int quarter, int pageNo, int size) { PageAnimeVO page new Page(pageNo, size); LambdaQueryWrapperAnime wrapper new LambdaQueryWrapper(); wrapper.eq(Anime::getSeasonYear, year) .eq(Anime::getSeasonQuarter, quarter) .eq(Anime::getStatus, 1) // 只查连载中 .orderByDesc(Anime::getCreatedAt); // 自定义分页查询避免 select * 带出 description 大字段 return animeMapper.selectVoPage(page, wrapper); }selectVoPage是自定义的 mapper 方法SQL 里只 select 列表页需要的字段id、title、cover_url、status把description这种大文本排除掉。参数size建议限制在 20 到 50 之间超过 100 时前端渲染会卡而且深分页LIMIT 10000, 20在 MySQL 上会扫描大量行。如果确实需要翻很深改用基于created_at的游标分页把WHERE created_at ?作为条件。3. 核心接口实现从登录鉴权到播放地址下发3.1 登录鉴权用 JWT 还是 Session动漫网站的用户端有 Web 和 App 两种形态Session 在跨端时要么依赖 Cookie 要么得自己做 token 映射比较别扭。我一般用 JWT把userId和过期时间签进 token服务端不存状态。代价是没法主动踢人下线但动漫网站对这块要求不高可以接受。public String generateToken(Long userId) { long now System.currentTimeMillis(); return Jwts.builder() .setSubject(String.valueOf(userId)) .setIssuedAt(new Date(now)) .setExpiration(new Date(now 7 * 24 * 3600 * 1000L)) // 7天 .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }SECRET_KEY必须从配置中心或环境变量读取不要硬编码在代码里。过期时间设 7 天是权衡结果太短用户频繁登录太长被盗后风险窗口大。如果要做「记住我」可以签发两个 token一个短期访问 token 加一个长期刷新 token刷新 token 存 Redis 并支持吊销。鉴权拦截器里解析 token 后把userId放进ThreadLocal业务层直接取避免每个方法都传参。请求结束时记得在afterCompletion里remove()否则线程池复用会导致用户身份串号这个坑我踩过。3.2 播放地址下发为什么要加一层签名直接把play_url返回给前端是最省事的但视频链接会被盗用别人拿到链接就能白嫖你的带宽。常见做法是返回一个带时效签名的地址比如https://cdn.example.com/video/123.mp4?signxxxexpire1730000000签名由后端用密钥对「路径 过期时间」计算CDN 侧校验。public String signPlayUrl(String rawUrl, long ttlSeconds) { long expire System.currentTimeMillis() / 1000 ttlSeconds; String path URI.create(rawUrl).getPath(); String toSign path | expire; String sign DigestUtils.md5Hex(toSign SIGN_SALT); return rawUrl ?sign sign expire expire; }ttlSeconds我一般设 7200也就是两小时够看完一集还有余量。SIGN_SALT和 JWT 的密钥分开管理泄露一个不影响另一个。CDN 侧的校验逻辑要和这里完全一致路径取的是 URL 的 path 部分不带 query否则签名对不上。3.3 播放进度上报的幂等处理前端播放器每 15 秒上报一次进度网络抖动时可能重复上报同一秒数。如果直接UPDATE问题不大但如果是「插入观看记录」就会产生重复行。用INSERT ... ON DUPLICATE KEY UPDATE配合唯一键最稳妥INSERT INTO user_follow (user_id, anime_id, last_episode_id, last_position, updated_at) VALUES (#{userId}, #{animeId}, #{episodeId}, #{position}, NOW()) ON DUPLICATE KEY UPDATE last_episode_id VALUES(last_episode_id), last_position IF(VALUES(last_position) last_position, VALUES(last_position), last_position), updated_at NOW();关键在last_position那行只有新上报的进度大于已存的才更新防止用户拖回开头重看时进度被覆盖成小值。这个IF判断是血泪经验早期没加用户反馈「看到第 10 分钟退出再进来变成第 2 分钟」。4. 弹幕与高并发写入削峰和查询缓存怎么做4.1 弹幕为什么不能直接写 MySQL弹幕的特点是「读多写多且集中」一集热门番更新瞬间几千条弹幕在几分钟内涌入。如果每条都直接 insert MySQL单表很快到千万级而且写入时行锁竞争会让接口响应变慢。我的方案是写入先落 Redis List用异步任务批量刷进 MySQL。public void sendDanmaku(Long episodeId, DanmakuDTO dto) { String key danmaku:buf: episodeId; String value JSON.toJSONString(dto); redisTemplate.opsForList().rightPush(key, value); // 控制缓冲区长度防止内存爆掉 Long size redisTemplate.opsForList().size(key); if (size ! null size 5000) { flushToDb(episodeId); } }danmaku:buf:{episodeId}这个 key 按集隔离避免不同集的弹幕互相干扰。缓冲区超过 5000 条就触发一次刷库同时后台有个定时任务每 30 秒兜底刷一次防止低峰期数据一直躺在 Redis 里。刷库时用批量 insert一次 500 条减少网络往返。4.2 弹幕查询按时间分片缓存用户拉取弹幕时是按播放时间区间请求的比如「第 60 秒到第 90 秒」。如果每次都查 MySQL 的WHERE time BETWEEN 60 AND 90即使有索引热门集也会被打爆。做法是把弹幕按 30 秒一个分片缓存到 Redispublic ListDanmakuVO loadDanmaku(Long episodeId, int fromSec, int toSec) { ListDanmakuVO result new ArrayList(); int startChunk fromSec / 30; int endChunk toSec / 30; for (int chunk startChunk; chunk endChunk; chunk) { String key danmaku:chunk: episodeId : chunk; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { result.addAll(JSON.parseArray(cached, DanmakuVO.class)); } else { ListDanmakuVO dbList danmakuMapper.selectByChunk(episodeId, chunk * 30, chunk * 30 30); redisTemplate.opsForValue().set(key, JSON.toJSONString(dbList), 10, TimeUnit.MINUTES); result.addAll(dbList); } } return result; }分片大小 30 秒是权衡太小则 key 数量爆炸太大则单次缓存命中率低。缓存过期设 10 分钟新弹幕写入后不主动删缓存靠过期自然刷新牺牲一点实时性换实现简单。如果产品要求弹幕秒级可见可以在刷库成功后删掉对应分片的 key。4.3 用 Redis 计数器做播放量统计播放量是典型的高频写、低频读场景每次播放都UPDATE anime SET views views 1会让这行成为热点。改用 Redis 的INCR定时同步到 MySQLpublic void recordPlay(Long animeId) { String key anime:views: animeId; redisTemplate.opsForValue().increment(key); } // 定时任务每5分钟执行 Scheduled(fixedRate 300000) public void syncViews() { SetString keys redisTemplate.keys(anime:views:*); for (String key : keys) { Long animeId Long.parseLong(key.substring(key.lastIndexOf(:) 1)); String value redisTemplate.opsForValue().get(key); if (value ! null) { animeMapper.updateViews(animeId, Long.parseLong(value)); redisTemplate.delete(key); } } }keys命令在生产环境要慎用数据量大时会阻塞 Redis。更稳的做法是用SCAN游标遍历或者维护一个「有更新的 animeId」集合定时任务只处理集合里的。同步时用UPDATE anime SET views views ?而不是直接赋值避免并发下丢计数。5. 部署与排查那些让接口 500 的坑5.1 数据库连接池配置不当导致接口超时现象本地跑得好好的部署到服务器后接口偶发超时日志里出现Connection is not available, request timed out。原因是 HikariCP 默认最大连接数 10而 Tomcat 默认最大线程 200高并发时大量线程在等连接。解决把maximum-pool-size调到和数据库max_connections匹配的值一般 20 到 50。同时设connection-timeout为 3000 毫秒让等不到连接的请求快速失败而不是一直挂起。spring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 10 connection-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000max-lifetime要小于 MySQL 的wait_timeout否则连接被数据库单方面断开后连接池还以为是好的取出来用就报错。MySQL 默认wait_timeout是 28800 秒设 1800000 毫秒30 分钟是安全的。5.2 跨域配置漏了 OPTIONS 预检请求现象前端调接口报 CORS 错误但后端明明加了CrossOrigin。打开 Network 面板发现 OPTIONS 请求返回 403。原因浏览器的预检请求不带 Cookie 和自定义头如果拦截器里对未登录请求直接返回 401OPTIONS 就被挡了。解决在拦截器里放行OPTIONS方法或者用 Spring 的CorsFilter在拦截器之前处理。Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } // 后续鉴权逻辑 }5.3 视频分片上传的临时文件没清理现象服务器磁盘几天就满了/tmp下堆了几万个upload_xxx.part文件。原因是分片上传合并后没删临时分片或者上传中断后残留。解决合并完成后立即删除分片目录同时加一个定时任务每天凌晨清理超过 24 小时的临时文件。分片目录按upload/{uploadId}/组织清理时按目录整体删。Scheduled(cron 0 0 3 * * ?) public void cleanTempFiles() { File tempDir new File(/data/tmp/upload); long expire System.currentTimeMillis() - 24 * 3600 * 1000L; File[] dirs tempDir.listFiles(); if (dirs null) return; for (File dir : dirs) { if (dir.lastModified() expire) { FileUtils.deleteQuietly(dir); } } }5.4 弹幕时间戳精度丢失导致位置偏移现象弹幕在播放器上显示的位置和发送时不一致越到后面偏移越大。原因是前端传的时间戳是浮点秒如 12.345后端存成INT时四舍五入累积误差。解决数据库存毫秒整数前端传值时乘以 1000 取整。查询时按毫秒比较返回给前端再除以 1000。字段类型用INT够用一集 24 分钟是 1440000 毫秒远小于INT上限。5.5 Redis 缓存穿透导致数据库压力骤增现象某个不存在的animeId被恶意刷接口每次请求都穿透 Redis 打到 MySQL。原因是缓存里没有这个 key查询数据库也查不到没有回写空值。解决查不到时往 Redis 写一个空标记过期时间设短一点比如 60 秒。同时接口层对animeId做范围校验明显非法的直接拒绝。public AnimeVO getAnime(Long animeId) { String key anime:info: animeId; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { return cached.isEmpty() ? null : JSON.parseObject(cached, AnimeVO.class); } AnimeVO vo animeMapper.selectVoById(animeId); if (vo null) { redisTemplate.opsForValue().set(key, , 60, TimeUnit.SECONDS); return null; } redisTemplate.opsForValue().set(key, JSON.toJSONString(vo), 30, TimeUnit.MINUTES); return vo; }6. 进阶技巧用定时任务框架把更新提醒做稳番剧更新提醒是动漫网站的留存利器但实现上有两个难点一是更新时间不固定日本动画经常跳票二是提醒要准时不能延迟太久。我一般用 Quartz 而不是 Spring 自带的Scheduled因为 Quartz 支持持久化任务和集群部署多实例下不会重复触发。核心思路是每部连载中的番剧在episode表里有一条publish_at记录定时任务扫描未来 10 分钟内要更新的剧集给追番用户发提醒。任务本身用 Quartz 的CronTrigger每分钟跑一次。DisallowConcurrentExecution public class AnimeUpdateJob implements Job { Override public void execute(JobExecutionContext context) { LocalDateTime now LocalDateTime.now(); LocalDateTime window now.plusMinutes(10); ListEpisode upcoming episodeMapper.selectByPublishWindow(now, window); for (Episode ep : upcoming) { ListLong userIds followMapper.selectUserIdsByAnimeId(ep.getAnimeId()); for (Long userId : userIds) { String key notify:sent: userId : ep.getId(); // 用 setnx 保证同一用户同一集只提醒一次 Boolean first redisTemplate.opsForValue() .setIfAbsent(key, 1, 24, TimeUnit.HOURS); if (Boolean.TRUE.equals(first)) { notifyService.push(userId, ep); } } } } }DisallowConcurrentExecution保证同一个 Job 不会并发执行避免多线程重复扫描。setIfAbsent是幂等关键即使任务因为重试跑了两次用户也只会收到一条提醒。selectByPublishWindow的 SQL 要命中idx_publish索引否则每分钟全表扫描会拖垮数据库。参数上扫描窗口设 10 分钟是因为任务每分钟跑一次留足余量应对任务延迟。提醒的过期时间设 24 小时覆盖用户可能错过的时间。如果用户量大push要改成异步队列别在 Job 里同步发。验证这套逻辑是否正常我会在测试环境手动改一条publish_at到 5 分钟后观察日志里是否出现notify:sent的 key以及用户是否收到推送。上线前还要压测一下模拟 1 万用户追同一部番看 Job 执行时间和 Redis 的 QPS 峰值。最后说个习惯每次改完定时任务我都会把CronTrigger的下次执行时间打出来核对一遍因为 cron 表达式写错一位就是凌晨三点跑或者根本不跑这种问题不主动验证很难发现。希望帮到你。本文还有配套的精品资源点击获取 Java动漫网站后端开发实战：数据模型、弹幕高并发与部署避坑
简介这份资源是面向Java Web初学者与系统设计人员的动漫网站毕业设计文档基于JSP、HTML结合MyEclipse与Tomcat采用B/S结构搭建动漫信息视频网站帮助读者理解从需求分析到功能落地的完整开发流程。系统涵盖动漫类别管理、动漫信息管理、动漫上传下载、会员信息管理及动漫资讯管理并区分管理员与会员两套角色体系后台以MySQL存储数据兼顾安全性与数据完整性。压缩包内为1个docx文件约816KB即郑州大学毕业设计论文全文包含中英文摘要、绪论、需求分析、系统设计、关键代码实现与系统测试等章节目录结构完整可直接作为同类选题的写作模板与开发参考。目前已有71人学习适合需要完成课程设计或毕业设计、希望快速掌握JSP网站开发思路的读者借鉴。1. 从零搭一个动漫网站Java 后端到底要解决哪些真问题很多人第一次接到「基于 Java 的动漫网站设计与实现系统开发」这类题目脑子里第一反应是套一个 Spring Boot 脚手架把用户、视频、评论三张表一建接口一写就完事。真跑起来才发现动漫网站和普通内容站根本不是一回事一集 24 分钟的视频要分片、要防盗链、要记录播放进度番剧有季度、有更新日历、有「追番」这种强关系数据弹幕是高频写入还要按时间轴对齐。这些需求决定了后端不能只做增删改查得把并发、缓存、事务边界都想清楚。这篇笔记面向两类人一是正在做课程设计或毕业设计、需要一套能跑通且讲得清技术选型的开发者二是想用 Java 技术栈练手一个真实业务系统的后端工程师。我会按「数据模型怎么设计 → 核心接口怎么写 → 播放与弹幕怎么扛住并发 → 部署和踩坑」的顺序讲代码基于 Spring Boot MyBatis 的常见组合数据库用 MySQL缓存用 Redis。凡是涉及具体参数的地方我都会给出可改的数值和调整依据你照着复现能跑起来也能看懂每一步为什么这么做。2. 动漫网站的数据模型番剧、剧集、用户关系怎么拆表2.1 为什么不能把「动漫」和「剧集」塞进一张表新手最容易犯的错是建一张anime表字段里塞episode_count、video_url结果一部番有 12 集就得存 12 条几乎重复的记录更新封面时改 12 次。正确做法是按内容层级拆成三张核心表anime作品、episode剧集、video_source播放源。一部作品对应多条剧集一集剧集可能对应多个清晰度的播放源这是典型的一对多再一对多。拆表带来的直接好处是更新作品信息只动一行剧集可以单独控制上架下架播放源可以按清晰度、线路分别管理某个 CDN 挂了只切对应源。代价是查询时要 join但这个 join 有索引支撑成本可控。-- 作品表一部番剧的元信息 CREATE TABLE anime ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL COMMENT 作品名, cover_url VARCHAR(255) COMMENT 封面图, season_year INT COMMENT 放送年份, season_quarter TINYINT COMMENT 1-4 对应春夏秋冬, status TINYINT DEFAULT 0 COMMENT 0未开播 1连载中 2已完结, description TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_season (season_year, season_quarter) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 剧集表一集一行 CREATE TABLE episode ( id BIGINT PRIMARY KEY AUTO_INCREMENT, anime_id BIGINT NOT NULL, episode_no INT NOT NULL COMMENT 第几集, title VARCHAR(128), duration INT COMMENT 时长秒, publish_at DATETIME COMMENT 更新时间, UNIQUE KEY uk_anime_ep (anime_id, episode_no), INDEX idx_publish (publish_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 播放源表一集多线路多清晰度 CREATE TABLE video_source ( id BIGINT PRIMARY KEY AUTO_INCREMENT, episode_id BIGINT NOT NULL, quality VARCHAR(16) COMMENT 360p/720p/1080p, line_name VARCHAR(32) COMMENT 线路A/线路B, play_url VARCHAR(512) NOT NULL, INDEX idx_episode (episode_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;anime表上的idx_season索引是为「本季新番」列表页准备的按年份加季度过滤是最常见的查询。episode表的唯一键uk_anime_ep保证同一部番不会出现重复集号这个约束在批量导入时能挡掉脏数据。video_source不设唯一键因为同一集同一清晰度允许有多条备用线路。2.2 追番关系表与播放进度表的设计取舍「追番」本质是用户和作品的多对多关系但直接建user_anime_follow中间表还不够因为列表页要按追番时间倒序展示还要显示「看到第几集」。我的做法是把追番关系和播放进度合并到一张表CREATE TABLE user_follow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, anime_id BIGINT NOT NULL, last_episode_id BIGINT COMMENT 最后观看的剧集, last_position INT DEFAULT 0 COMMENT 播放进度秒, followed_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_anime (user_id, anime_id), INDEX idx_user_time (user_id, updated_at DESC) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;合并的理由是用户点「追番」和「继续观看」在业务上高度重合分开两张表会导致每次进个人中心要 join 两次。合并后idx_user_time直接支撑「我的追番」按最近观看排序。last_position记录秒数前端播放器每 15 秒上报一次后端做 upsert。注意updated_at用ON UPDATE CURRENT_TIMESTAMP自动维护但批量更新进度时如果值没变 MySQL 不会触发更新所以上报接口里要显式SET updated_at NOW()。2.3 用 MyBatis 写分页查询的常见写法列表页几乎都要分页MyBatis-Plus 的Page对象是最省事的方案但要注意 count 查询的性能。下面是一个按季度查番剧的分页方法public PageAnimeVO listBySeason(int year, int quarter, int pageNo, int size) { PageAnimeVO page new Page(pageNo, size); LambdaQueryWrapperAnime wrapper new LambdaQueryWrapper(); wrapper.eq(Anime::getSeasonYear, year) .eq(Anime::getSeasonQuarter, quarter) .eq(Anime::getStatus, 1) // 只查连载中 .orderByDesc(Anime::getCreatedAt); // 自定义分页查询避免 select * 带出 description 大字段 return animeMapper.selectVoPage(page, wrapper); }selectVoPage是自定义的 mapper 方法SQL 里只 select 列表页需要的字段id、title、cover_url、status把description这种大文本排除掉。参数size建议限制在 20 到 50 之间超过 100 时前端渲染会卡而且深分页LIMIT 10000, 20在 MySQL 上会扫描大量行。如果确实需要翻很深改用基于created_at的游标分页把WHERE created_at ?作为条件。3. 核心接口实现从登录鉴权到播放地址下发3.1 登录鉴权用 JWT 还是 Session动漫网站的用户端有 Web 和 App 两种形态Session 在跨端时要么依赖 Cookie 要么得自己做 token 映射比较别扭。我一般用 JWT把userId和过期时间签进 token服务端不存状态。代价是没法主动踢人下线但动漫网站对这块要求不高可以接受。public String generateToken(Long userId) { long now System.currentTimeMillis(); return Jwts.builder() .setSubject(String.valueOf(userId)) .setIssuedAt(new Date(now)) .setExpiration(new Date(now 7 * 24 * 3600 * 1000L)) // 7天 .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }SECRET_KEY必须从配置中心或环境变量读取不要硬编码在代码里。过期时间设 7 天是权衡结果太短用户频繁登录太长被盗后风险窗口大。如果要做「记住我」可以签发两个 token一个短期访问 token 加一个长期刷新 token刷新 token 存 Redis 并支持吊销。鉴权拦截器里解析 token 后把userId放进ThreadLocal业务层直接取避免每个方法都传参。请求结束时记得在afterCompletion里remove()否则线程池复用会导致用户身份串号这个坑我踩过。3.2 播放地址下发为什么要加一层签名直接把play_url返回给前端是最省事的但视频链接会被盗用别人拿到链接就能白嫖你的带宽。常见做法是返回一个带时效签名的地址比如https://cdn.example.com/video/123.mp4?signxxxexpire1730000000签名由后端用密钥对「路径 过期时间」计算CDN 侧校验。public String signPlayUrl(String rawUrl, long ttlSeconds) { long expire System.currentTimeMillis() / 1000 ttlSeconds; String path URI.create(rawUrl).getPath(); String toSign path | expire; String sign DigestUtils.md5Hex(toSign SIGN_SALT); return rawUrl ?sign sign expire expire; }ttlSeconds我一般设 7200也就是两小时够看完一集还有余量。SIGN_SALT和 JWT 的密钥分开管理泄露一个不影响另一个。CDN 侧的校验逻辑要和这里完全一致路径取的是 URL 的 path 部分不带 query否则签名对不上。3.3 播放进度上报的幂等处理前端播放器每 15 秒上报一次进度网络抖动时可能重复上报同一秒数。如果直接UPDATE问题不大但如果是「插入观看记录」就会产生重复行。用INSERT ... ON DUPLICATE KEY UPDATE配合唯一键最稳妥INSERT INTO user_follow (user_id, anime_id, last_episode_id, last_position, updated_at) VALUES (#{userId}, #{animeId}, #{episodeId}, #{position}, NOW()) ON DUPLICATE KEY UPDATE last_episode_id VALUES(last_episode_id), last_position IF(VALUES(last_position) last_position, VALUES(last_position), last_position), updated_at NOW();关键在last_position那行只有新上报的进度大于已存的才更新防止用户拖回开头重看时进度被覆盖成小值。这个IF判断是血泪经验早期没加用户反馈「看到第 10 分钟退出再进来变成第 2 分钟」。4. 弹幕与高并发写入削峰和查询缓存怎么做4.1 弹幕为什么不能直接写 MySQL弹幕的特点是「读多写多且集中」一集热门番更新瞬间几千条弹幕在几分钟内涌入。如果每条都直接 insert MySQL单表很快到千万级而且写入时行锁竞争会让接口响应变慢。我的方案是写入先落 Redis List用异步任务批量刷进 MySQL。public void sendDanmaku(Long episodeId, DanmakuDTO dto) { String key danmaku:buf: episodeId; String value JSON.toJSONString(dto); redisTemplate.opsForList().rightPush(key, value); // 控制缓冲区长度防止内存爆掉 Long size redisTemplate.opsForList().size(key); if (size ! null size 5000) { flushToDb(episodeId); } }danmaku:buf:{episodeId}这个 key 按集隔离避免不同集的弹幕互相干扰。缓冲区超过 5000 条就触发一次刷库同时后台有个定时任务每 30 秒兜底刷一次防止低峰期数据一直躺在 Redis 里。刷库时用批量 insert一次 500 条减少网络往返。4.2 弹幕查询按时间分片缓存用户拉取弹幕时是按播放时间区间请求的比如「第 60 秒到第 90 秒」。如果每次都查 MySQL 的WHERE time BETWEEN 60 AND 90即使有索引热门集也会被打爆。做法是把弹幕按 30 秒一个分片缓存到 Redispublic ListDanmakuVO loadDanmaku(Long episodeId, int fromSec, int toSec) { ListDanmakuVO result new ArrayList(); int startChunk fromSec / 30; int endChunk toSec / 30; for (int chunk startChunk; chunk endChunk; chunk) { String key danmaku:chunk: episodeId : chunk; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { result.addAll(JSON.parseArray(cached, DanmakuVO.class)); } else { ListDanmakuVO dbList danmakuMapper.selectByChunk(episodeId, chunk * 30, chunk * 30 30); redisTemplate.opsForValue().set(key, JSON.toJSONString(dbList), 10, TimeUnit.MINUTES); result.addAll(dbList); } } return result; }分片大小 30 秒是权衡太小则 key 数量爆炸太大则单次缓存命中率低。缓存过期设 10 分钟新弹幕写入后不主动删缓存靠过期自然刷新牺牲一点实时性换实现简单。如果产品要求弹幕秒级可见可以在刷库成功后删掉对应分片的 key。4.3 用 Redis 计数器做播放量统计播放量是典型的高频写、低频读场景每次播放都UPDATE anime SET views views 1会让这行成为热点。改用 Redis 的INCR定时同步到 MySQLpublic void recordPlay(Long animeId) { String key anime:views: animeId; redisTemplate.opsForValue().increment(key); } // 定时任务每5分钟执行 Scheduled(fixedRate 300000) public void syncViews() { SetString keys redisTemplate.keys(anime:views:*); for (String key : keys) { Long animeId Long.parseLong(key.substring(key.lastIndexOf(:) 1)); String value redisTemplate.opsForValue().get(key); if (value ! null) { animeMapper.updateViews(animeId, Long.parseLong(value)); redisTemplate.delete(key); } } }keys命令在生产环境要慎用数据量大时会阻塞 Redis。更稳的做法是用SCAN游标遍历或者维护一个「有更新的 animeId」集合定时任务只处理集合里的。同步时用UPDATE anime SET views views ?而不是直接赋值避免并发下丢计数。5. 部署与排查那些让接口 500 的坑5.1 数据库连接池配置不当导致接口超时现象本地跑得好好的部署到服务器后接口偶发超时日志里出现Connection is not available, request timed out。原因是 HikariCP 默认最大连接数 10而 Tomcat 默认最大线程 200高并发时大量线程在等连接。解决把maximum-pool-size调到和数据库max_connections匹配的值一般 20 到 50。同时设connection-timeout为 3000 毫秒让等不到连接的请求快速失败而不是一直挂起。spring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 10 connection-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000max-lifetime要小于 MySQL 的wait_timeout否则连接被数据库单方面断开后连接池还以为是好的取出来用就报错。MySQL 默认wait_timeout是 28800 秒设 1800000 毫秒30 分钟是安全的。5.2 跨域配置漏了 OPTIONS 预检请求现象前端调接口报 CORS 错误但后端明明加了CrossOrigin。打开 Network 面板发现 OPTIONS 请求返回 403。原因浏览器的预检请求不带 Cookie 和自定义头如果拦截器里对未登录请求直接返回 401OPTIONS 就被挡了。解决在拦截器里放行OPTIONS方法或者用 Spring 的CorsFilter在拦截器之前处理。Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } // 后续鉴权逻辑 }5.3 视频分片上传的临时文件没清理现象服务器磁盘几天就满了/tmp下堆了几万个upload_xxx.part文件。原因是分片上传合并后没删临时分片或者上传中断后残留。解决合并完成后立即删除分片目录同时加一个定时任务每天凌晨清理超过 24 小时的临时文件。分片目录按upload/{uploadId}/组织清理时按目录整体删。Scheduled(cron 0 0 3 * * ?) public void cleanTempFiles() { File tempDir new File(/data/tmp/upload); long expire System.currentTimeMillis() - 24 * 3600 * 1000L; File[] dirs tempDir.listFiles(); if (dirs null) return; for (File dir : dirs) { if (dir.lastModified() expire) { FileUtils.deleteQuietly(dir); } } }5.4 弹幕时间戳精度丢失导致位置偏移现象弹幕在播放器上显示的位置和发送时不一致越到后面偏移越大。原因是前端传的时间戳是浮点秒如 12.345后端存成INT时四舍五入累积误差。解决数据库存毫秒整数前端传值时乘以 1000 取整。查询时按毫秒比较返回给前端再除以 1000。字段类型用INT够用一集 24 分钟是 1440000 毫秒远小于INT上限。5.5 Redis 缓存穿透导致数据库压力骤增现象某个不存在的animeId被恶意刷接口每次请求都穿透 Redis 打到 MySQL。原因是缓存里没有这个 key查询数据库也查不到没有回写空值。解决查不到时往 Redis 写一个空标记过期时间设短一点比如 60 秒。同时接口层对animeId做范围校验明显非法的直接拒绝。public AnimeVO getAnime(Long animeId) { String key anime:info: animeId; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { return cached.isEmpty() ? null : JSON.parseObject(cached, AnimeVO.class); } AnimeVO vo animeMapper.selectVoById(animeId); if (vo null) { redisTemplate.opsForValue().set(key, , 60, TimeUnit.SECONDS); return null; } redisTemplate.opsForValue().set(key, JSON.toJSONString(vo), 30, TimeUnit.MINUTES); return vo; }6. 进阶技巧用定时任务框架把更新提醒做稳番剧更新提醒是动漫网站的留存利器但实现上有两个难点一是更新时间不固定日本动画经常跳票二是提醒要准时不能延迟太久。我一般用 Quartz 而不是 Spring 自带的Scheduled因为 Quartz 支持持久化任务和集群部署多实例下不会重复触发。核心思路是每部连载中的番剧在episode表里有一条publish_at记录定时任务扫描未来 10 分钟内要更新的剧集给追番用户发提醒。任务本身用 Quartz 的CronTrigger每分钟跑一次。DisallowConcurrentExecution public class AnimeUpdateJob implements Job { Override public void execute(JobExecutionContext context) { LocalDateTime now LocalDateTime.now(); LocalDateTime window now.plusMinutes(10); ListEpisode upcoming episodeMapper.selectByPublishWindow(now, window); for (Episode ep : upcoming) { ListLong userIds followMapper.selectUserIdsByAnimeId(ep.getAnimeId()); for (Long userId : userIds) { String key notify:sent: userId : ep.getId(); // 用 setnx 保证同一用户同一集只提醒一次 Boolean first redisTemplate.opsForValue() .setIfAbsent(key, 1, 24, TimeUnit.HOURS); if (Boolean.TRUE.equals(first)) { notifyService.push(userId, ep); } } } } }DisallowConcurrentExecution保证同一个 Job 不会并发执行避免多线程重复扫描。setIfAbsent是幂等关键即使任务因为重试跑了两次用户也只会收到一条提醒。selectByPublishWindow的 SQL 要命中idx_publish索引否则每分钟全表扫描会拖垮数据库。参数上扫描窗口设 10 分钟是因为任务每分钟跑一次留足余量应对任务延迟。提醒的过期时间设 24 小时覆盖用户可能错过的时间。如果用户量大push要改成异步队列别在 Job 里同步发。验证这套逻辑是否正常我会在测试环境手动改一条publish_at到 5 分钟后观察日志里是否出现notify:sent的 key以及用户是否收到推送。上线前还要压测一下模拟 1 万用户追同一部番看 Job 执行时间和 Redis 的 QPS 峰值。最后说个习惯每次改完定时任务我都会把CronTrigger的下次执行时间打出来核对一遍因为 cron 表达式写错一位就是凌晨三点跑或者根本不跑这种问题不主动验证很难发现。希望帮到你。本文还有配套的精品资源点击获取