简介这是一套基于Java Web技术栈开发的会议室预约系统实战项目面向Java初学者与Web开发入门者解决企业内部会议室资源调度混乱、预约冲突频发等管理痛点适用于课程设计、毕业设计或中小团队轻量级协同场景。资源包共744个文件涵盖20个JSP页面核心业务逻辑与交互入口、212个JS脚本表单验证、日历控件与前端交互、74个HTML静态页辅助说明与跳转、31个CSS样式文件界面美化、26个CSS样式文件及229个GIF图标资源UI组件与状态提示整体压缩包仅5.01MB结构清晰、模块完整。已有1659人学习下载资源包含可直接部署运行的完整工程含部门/员工/会议室/公告四大核心模块的数据库SQL脚本、Servlet控制层代码、JavaBean数据模型及FCKeditor富文本集成示例如config.ascx、io.asp等便于理解MVC分层实践与传统Java Web开发全流程。1. 为什么一个“会议室预约”系统反而最容易在毕设答辩里被问住不是功能太少而是太容易想当然。某高校课程设计里A同学用JSPServletMySQL搭了个能填时间、选房间、点提交的页面自测跑通就交了——结果答辩时被连问三轮“用户重复预约怎么拦同一时段两个部门同时点提交谁的请求生效管理员删掉一条预约后所有依赖它的会议通知是否自动失效”——当场卡壳。这暴露了一个现实会议室预约表面是CRUD内核却是并发控制、状态流转、业务闭环的微型调度系统。它不追求炫技但必须经得起“如果……会怎样”的连续追问。本方案面向需要交付完整可运行系统的本科生与初级开发者覆盖从需求建模含冲突场景预判、三层架构落地JSP做视图层不写Java逻辑、MySQL事务隔离级实测配置、到6类典型并发/异常场景的防御式编码。所有代码模块可独立编译数据库脚本带初始化数据部署即验文末附答辩高频问题清单与逐条应答话术。你不需要从零造轮子但得知道每个轮子为什么这么造。2. 需求解构与核心约束把“预约”拆成可验证的原子动作会议室预约不是“用户填表→存库→完事”而是一组强约束的原子操作链。我们先剥离业务表象聚焦系统必须守住的底线。2.1 业务规则显性化从模糊描述到可执行条款很多同学直接写“用户可以预约会议室”但这句话在代码里毫无意义。必须翻译成机器可校验的条款时间不可重叠同一会议室在任一时刻只能被一个有效预约占用注意“有效”指状态为confirmed不包括pending或cancelled资源强绑定预约记录必须关联唯一会议室ID、唯一申请人ID、唯一时间段start_time duration三者缺一不可状态机驱动预约生命周期严格遵循created → pending → confirmed/cancelled → archived禁止跨状态跳转如created直跳archived权限隔离普通用户仅能操作自己发起的pending/confirmed预约管理员可操作全部但删除操作需记录操作人与时间戳冲突熔断当检测到时间/资源冲突时系统必须拒绝提交并返回具体冲突对象如“该时段已被【市场部周例会】占用”而非仅提示“预约失败”。提示这些条款不是写在文档里就完事它们将直接映射到数据库约束如唯一索引、Service层校验逻辑、甚至前端禁用策略。例如“时间不可重叠”在MySQL中需用INSERT ... SELECT配合NOT EXISTS子查询实现而非靠应用层SELECT COUNT(*)再INSERT——后者在高并发下必然漏判。2.2 数据模型设计用范式平衡与业务直觉本系统采用3NF设计但对高频查询做了适度冗余。核心表结构如下关键字段加粗标注表名字段关键说明meeting_roomroom_id(PK),room_name,capacity,status(enum: available,maintenance)会议室基础信息status用于物理停用不影响预约逻辑user_infouser_id(PK),username,department,role(enum: user,admin)用户角色决定操作权限边界reservationres_id(PK),room_id(FK),user_id(FK),start_time(DATETIME),duration_min(INT),status(enum: created,pending,confirmed,cancelled,archived)**,create_time,update_time预约主表start_timeduration_min定义时段避免存储end_time引发计算不一致reservation_loglog_id(PK),res_id(FK),operator_id,action(enum: create,confirm,cancel,delete),action_time,remark操作审计日志答辩时可演示“谁在何时做了什么”关键设计点说明reservation表未设end_time字段因duration_min可能动态调整如用户延长会议若存end_time则每次修改需同步更新易出错。所有时间计算均基于start_time INTERVAL duration_min MINUTEstatus字段用ENUM而非INT避免非法状态写入MySQL层面强制校验减少Service层if-elsereservation_log独立建表不与reservation耦合便于按需归档且审计日志需永久保留与业务数据生命周期分离。2.3 并发场景预演画出你的系统“压力测试地图”不要等答辩被问才想并发问题。我们提前模拟6类真实压力点每类对应代码层防御策略场景触发条件系统风险防御位置验证方式双写冲突用户A/B同时预约同一会议室同一时段两条confirmed记录入库违反时间不可重叠MySQL唯一索引Service层乐观锁手动开两个浏览器Tab并发提交查数据库是否仅1条成功状态越权普通用户调用/admin/delete?id100接口删除他人预约Controller层PreAuthorize注解Service层二次校验Postman构造带他人ID的DELETE请求检查返回403时间漂移用户提交start_time2024-05-20 09:00:00但服务器时区为UTC预约时段错位8小时全局统一使用Asia/Shanghai时区JDBC连接串加serverTimezoneAsia/Shanghai在Linux服务器用date命令确认时区插入后查数据库时间是否匹配幻读漏洞管理员查看“今日待确认预约”列表时另一线程刚确认了一条列表显示已确认的预约导致重复操作查询列表时用SELECT ... FOR UPDATE锁定行用两个线程交替执行“查列表”和“确认预约”观察列表是否实时刷新脏读风险Service方法内部分事务回滚但已发送邮件通知收到通知却预约失败事务边界包裹整个业务流含邮件发送失败则全部回滚故意让邮件发送抛异常检查数据库预约记录是否未创建长事务阻塞confirmReservation()方法中嵌套调用耗时API如钉钉通知数据库连接池耗尽其他请求超时将非核心操作通知拆出事务用异步队列如内存队列解耦压测时监控show processlist确认无长时间Sleep连接这些不是理论假设而是某次课程设计部署后真实发生的翻车点。接下来章节我们将逐个击破。3. 总体架构设计JSPServletMySQL三层结构的务实落地本方案放弃Spring Boot等框架回归Servlet原生开发——不是为了复古而是确保你能清晰看到每一层的数据流向与责任边界。三层结构不是摆设而是调试时的救命索引。3.1 技术栈选型依据为什么坚持用原生Servlet教学穿透性JSP本质是Servlet的语法糖用原生Servlet能让你看清HttpServletRequest如何解析表单、HttpServletResponse如何写回JSON、Filter如何拦截请求。某高校导师反馈用Spring Boot的学生在答辩时说不清“RequestBody是怎么把JSON转成对象的”而用Servlet的同学能画出ObjectMapper调用链轻量可控无需管理application.properties多环境配置、Starter依赖冲突、自动装配原理。一个web.xml文件定义所有Servlet映射pom.xml仅含javax.servlet-api和mysql-connector-java两个核心依赖调试友好断点可直接打在doPost()方法内观察request.getParameter(room_id)值、session.getAttribute(user_id)状态、SQL执行前后的connection对象。没有代理、反射、AOP的黑匣子干扰。注意本方案中的JSP仅作纯视图渲染禁止在JSP中写Java代码% %、调用Service层方法。所有业务逻辑必须在Servlet或Service类中处理JSP只通过request.setAttribute()接收数据用JSTL标签c:forEach遍历展示。这是答辩时老师重点检查的规范项。3.2 包结构与职责划分让代码目录成为你的设计说明书src/ ├── main/ │ ├── java/ │ │ └── com.example.meeting/ │ │ ├── controller/ // Servlet入口只做参数接收、调用Service、转发/重定向 │ │ │ ├── ReservationServlet.java // 处理预约增删改查 │ │ │ └── AdminServlet.java // 管理员专用操作 │ │ ├── service/ // 业务逻辑核心含事务管理、状态校验、并发控制 │ │ │ ├── ReservationService.java // 主服务类Transactional注解在此 │ │ │ └── NotificationService.java // 通知发送邮件/站内信异步解耦 │ │ ├── dao/ // 数据访问纯SQL操作不处理业务规则 │ │ │ ├── ReservationDao.java // CRUD方法返回POJO │ │ │ └── LogDao.java // 审计日志写入 │ │ ├── model/ // POJO实体与数据库表一一对应 │ │ │ ├── Reservation.java │ │ │ └── User.java │ │ └── util/ // 工具类如DBUtil获取Connection、DateUtil │ └── webapp/ │ ├── WEB-INF/ │ │ ├── web.xml // Servlet注册、Filter配置、欢迎页 │ │ └── jsp/ // JSP页面按功能分目录 │ │ ├── user/ // 普通用户页面 │ │ │ ├── index.jsp // 首页可预约列表 │ │ │ └── myReservations.jsp // 我的预约 │ │ └── admin/ // 管理员页面 │ │ └── confirmList.jsp // 待确认列表 │ └── static/ // CSS/JS/图片静态资源 └── resources/ └── db.properties // 数据库连接配置driver,url,user,pass关键约定controller层方法名与HTTP路径强对应ReservationServlet.doPost()处理/reservation所有POST请求内部用request.getParameter(action)区分create/cancel/confirmservice层方法必须以业务动词开头createReservation()、confirmReservation()、cancelReservation()禁止process()、handle()等模糊命名dao层方法名体现SQL意图insertReservation()、selectReservationById()、updateReservationStatus()不出现get()、find()等泛化词。3.3 数据库连接与事务管理手写JDBC的硬核细节不用Hibernate意味着你要亲手管理Connection、PreparedStatement、Transaction。这不是倒退而是掌握底层的关键。// src/main/java/com/example/meeting/util/DBUtil.java public class DBUtil { private static DataSource dataSource; static { try { Properties props new Properties(); props.load(DBUtil.class.getClassLoader().getResourceAsStream(db.properties)); // 关键启用MySQL的可重复读隔离级别并设置时区 String url props.getProperty(url) ?useSSLfalseserverTimezoneAsia/ShanghaitransactionIsolationTRANSACTION_REPEATABLE_READ; dataSource new BasicDataSource(); dataSource.setUrl(url); dataSource.setUsername(props.getProperty(user)); dataSource.setPassword(props.getProperty(pass)); dataSource.setInitialSize(5); dataSource.setMaxIdle(10); dataSource.setMinIdle(5); } catch (Exception e) { throw new RuntimeException(DBUtil init failed, e); } } public static Connection getConnection() throws SQLException { Connection conn dataSource.getConnection(); // 关键所有业务操作默认开启事务避免自动提交 conn.setAutoCommit(false); return conn; } }为什么选TRANSACTION_REPEATABLE_READ这是MySQL默认隔离级别能防止脏读、不可重复读且比SERIALIZABLE性能更好。对于会议室预约“幻读”风险可通过应用层唯一索引业务校验兜底无需牺牲并发性能。事务边界在哪在ReservationService的每个公共方法上// src/main/java/com/example/meeting/service/ReservationService.java public class ReservationService { private final ReservationDao reservationDao; private final LogDao logDao; public ReservationService() { this.reservationDao new ReservationDao(); this.logDao new LogDao(); } Transactional // 此注解为示意实际用try-catch手动commit/rollback public boolean createReservation(Reservation reservation) throws SQLException { Connection conn null; try { conn DBUtil.getConnection(); // 1. 校验时间冲突关键用SELECT FOR UPDATE锁定相关行 if (hasTimeConflict(conn, reservation.getRoomId(), reservation.getStartTime(), reservation.getDurationMin())) { throw new BusinessException(该时段已被占用); } // 2. 插入预约记录 reservationDao.insertReservation(conn, reservation); // 3. 记录操作日志 logDao.insertLog(conn, reservation.getResId(), reservation.getUserId(), create, 预约创建); conn.commit(); // 显式提交 return true; } catch (BusinessException e) { if (conn ! null) conn.rollback(); // 业务异常回滚 throw e; } catch (Exception e) { if (conn ! null) conn.rollback(); // 系统异常回滚 throw new RuntimeException(预约创建失败, e); } finally { if (conn ! null) conn.close(); } } }避坑 / 常见问题 / 排查 / 注意3.4 并发与事务避坑指南那些让你深夜改bug的细节现象本地Tomcat测试正常部署到Linux服务器后频繁出现“预约失败该时段已被占用”但数据库查不到冲突记录。原因服务器JVM时区与MySQL时区不一致。Java默认用系统时区若Linuxdate显示UTC而MySQLSELECT time_zone返回SYSTEM即UTC但Javanew Date()生成的时间戳被当作CST东八区处理导致时间计算偏移8小时。解决在db.properties的JDBC URL中强制指定serverTimezoneAsia/Shanghai并在Java代码中所有时间操作前加TimeZone.setDefault(TimeZone.getTimeZone(Asia/Shanghai));。现象用户点击“取消预约”后页面跳转到首页但数据库中状态仍是confirmed。原因Servlet中调用了cancelReservation()方法但未检查其返回值也未处理SQLException。异常被吞掉conn.rollback()未执行事务自动提交。解决所有Service方法调用后必须判断返回值如if (!service.cancelReservation(id)) { request.setAttribute(error, 取消失败); }且catch块中必须显式rollback()并重新抛出。现象管理员在“待确认列表”点击确认后该预约消失但其他用户刷新列表仍能看到。原因查询列表的SQL未加FOR UPDATE导致读取的是快照数据。当A线程确认预约更新status时B线程的查询结果还未刷新。解决在AdminServlet查询待确认列表时DAO层使用SELECT * FROM reservation WHERE statuspending FOR UPDATE确保读取最新数据并锁定行。现象高并发预约时MySQL报错Lock wait timeout exceeded。原因SELECT ... FOR UPDATE锁定了过多行如查询所有可用会议室或锁持有时间过长如在事务中调用外部API。解决缩小锁范围——只对目标会议室ID加锁将耗时操作如邮件发送移出事务用ExecutorService异步执行。现象用户修改预约时间后原时段未释放新时段又无法预约因原记录status未变。原因updateReservation()方法只更新了start_time和duration_min未校验新时段是否与自身旧时段冲突也未将旧状态置为cancelled。解决修改逻辑为“先取消原预约update status to cancelled再创建新预约insert new record”确保状态机流转正确。4. 核心模块实现从预约创建到状态确认的完整链路现在进入最硬核的部分把需求条款翻译成可运行的代码。我们聚焦三个高频操作——创建预约、确认预约、取消预约每个都包含数据库交互、并发防护、错误反馈的完整闭环。4.1 预约创建用唯一索引业务校验双保险防冲突创建预约是并发冲突最高发的环节。单纯依赖应用层SELECT COUNT(*)校验在高并发下必然失败。本方案采用“数据库唯一约束兜底 应用层精准提示”组合拳。第一步建唯一索引让MySQL替你挡枪-- 在reservation表上创建复合唯一索引覆盖会议室时段维度 CREATE UNIQUE INDEX uk_room_time ON reservation (room_id, start_time, duration_min);但此索引有缺陷start_time和duration_min组合不能精确表达“时段重叠”。例如A预约09:00-10:0060分钟B预约09:30-10:3060分钟两者start_time不同、duration_min相同索引不触发冲突。因此必须辅以应用层校验。第二步Service层精准冲突检测带行锁// src/main/java/com/example/meeting/service/ReservationService.java private boolean hasTimeConflict(Connection conn, int roomId, Timestamp startTime, int durationMin) throws SQLException { // 计算时段边界start_time 和 end_time Timestamp endTime new Timestamp(startTime.getTime() durationMin * 60 * 1000L); // 关键用SELECT FOR UPDATE锁定所有可能冲突的记录 String sql SELECT res_id FROM reservation WHERE room_id ? AND status confirmed AND ( (? BETWEEN start_time AND DATE_ADD(start_time, INTERVAL duration_min MINUTE)) OR (? BETWEEN start_time AND DATE_ADD(start_time, INTERVAL duration_min MINUTE)) OR (start_time BETWEEN ? AND ?) ) FOR UPDATE; try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setInt(1, roomId); ps.setTimestamp(2, startTime); // 新预约start ps.setTimestamp(3, endTime); // 新预约end ps.setTimestamp(4, startTime); // 新预约start ps.setTimestamp(5, endTime); // 新预约end try (ResultSet rs ps.executeQuery()) { return rs.next(); // 有记录即冲突 } } }第三步Controller层参数校验与错误透传// src/main/java/com/example/meeting/controller/ReservationServlet.java protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String action request.getParameter(action); if (create.equals(action)) { try { // 1. 参数校验非空、数字格式 int roomId getIntParam(request, room_id); String startStr request.getParameter(start_time); int duration getIntParam(request, duration_min); // 2. 转换时间强制指定时区 SimpleDateFormat sdf new SimpleDateFormat(yyyy-MM-dd HH:mm:ss); sdf.setTimeZone(TimeZone.getTimeZone(Asia/Shanghai)); Timestamp startTime new Timestamp(sdf.parse(startStr).getTime()); // 3. 构建预约对象 Reservation reservation new Reservation(); reservation.setRoomId(roomId); reservation.setUserId((Integer) request.getSession().getAttribute(user_id)); reservation.setStartTime(startTime); reservation.setDurationMin(duration); reservation.setStatus(pending); // 初始状态为pending待管理员确认 // 4. 调用Service boolean success reservationService.createReservation(reservation); if (success) { request.setAttribute(message, 预约已提交等待管理员确认); } else { request.setAttribute(error, 预约失败请重试); } } catch (ParseException e) { request.setAttribute(error, 时间格式错误请按 yyyy-MM-dd HH:mm:ss 输入); } catch (BusinessException e) { // 业务异常如冲突透传给前端 request.setAttribute(error, e.getMessage()); } catch (Exception e) { request.setAttribute(error, 系统繁忙请稍后重试); e.printStackTrace(); // 开发期打印上线改为日志 } } request.getRequestDispatcher(/WEB-INF/jsp/user/index.jsp).forward(request, response); }设计说明getIntParam()是工具方法封装Integer.parseInt()并捕获NumberFormatException避免空指针时间转换强制TimeZone.getTimeZone(Asia/Shanghai)确保与数据库时区一致status设为pending而非confirmed体现“预约需审批”的业务规则BusinessException是自定义异常专用于携带用户友好的错误消息区别于SQLException等系统异常。4.2 管理员确认状态机驱动的原子操作确认预约不是简单UPDATE statusconfirmed而是状态机的一次跃迁需满足前置条件、记录审计、触发通知。// src/main/java/com/example/meeting/service/ReservationService.java public boolean confirmReservation(int resId, int operatorId) throws SQLException { Connection conn null; try { conn DBUtil.getConnection(); // 1. 检查当前状态是否为pending状态机约束 Reservation current reservationDao.selectReservationById(conn, resId); if (!pending.equals(current.getStatus())) { throw new BusinessException(只能确认待确认状态的预约); } // 2. 再次校验时间冲突防止在pending期间被其他pending预约抢占 if (hasTimeConflict(conn, current.getRoomId(), current.getStartTime(), current.getDurationMin())) { throw new BusinessException(该时段已被其他预约占用请刷新列表); } // 3. 更新状态 reservationDao.updateStatus(conn, resId, confirmed); // 4. 记录审计日志 logDao.insertLog(conn, resId, operatorId, confirm, 管理员确认预约); // 5. 异步发送通知移出事务 notificationService.sendConfirmationEmailAsync(current, operatorId); conn.commit(); return true; } catch (Exception e) { if (conn ! null) conn.rollback(); throw e; } finally { if (conn ! null) conn.close(); } }关键点双重校验先查状态再校冲突确保即使pending状态被并发修改也能及时发现异步通知sendConfirmationEmailAsync()内部使用Executors.newSingleThreadExecutor()避免邮件发送超时拖垮事务审计必留logDao.insertLog()在事务内执行确保操作与状态变更原子性。4.3 用户取消软删除与状态回滚的边界用户取消预约需区分场景pending状态可直接取消confirmed状态需管理员二次审核本方案简化为允许用户取消但记录cancelled_by_user标记。// src/main/java/com/example/meeting/service/ReservationService.java public boolean cancelReservation(int resId, int userId) throws SQLException { Connection conn null; try { conn DBUtil.getConnection(); Reservation reservation reservationDao.selectReservationById(conn, resId); // 1. 权限校验只能取消自己的预约 if (reservation.getUserId() ! userId) { throw new BusinessException(无权操作他人预约); } // 2. 状态校验confirmed状态需特殊处理 if (confirmed.equals(reservation.getStatus())) { // 允许用户取消但状态变为cancelled_by_user便于管理员追溯 reservationDao.updateStatusAndRemark(conn, resId, cancelled_by_user, 用户主动取消); } else if (pending.equals(reservation.getStatus())) { reservationDao.updateStatus(conn, resId, cancelled); } else { throw new BusinessException(当前状态不允许取消); } logDao.insertLog(conn, resId, userId, cancel, 用户取消预约); conn.commit(); return true; } catch (Exception e) { if (conn ! null) conn.rollback(); throw e; } finally { if (conn ! null) conn.close(); } }设计说明updateStatusAndRemark()是DAO层新增方法更新status和remark字段remark用于记录取消原因不提供delete from reservation物理删除所有操作均为状态变更符合数据审计要求cancelled_by_user状态在统计报表中可单独过滤不影响confirmed总数。5. 验收与答辩用可演示的证据链说服评委验收不是“跑起来就行”而是构建一条从需求条款到代码实现、再到运行证据的完整证据链。评委要的不是你“知道”而是你“做到并验证过”。以下是我带过的多个项目总结出的硬核验收法——不讲虚的只列你能立刻执行的动作。5.1 功能验收清单对照需求条款逐条演示拿出一张白纸按2.1节的5条业务规则每条对应一个可截图的操作步骤。不要口头描述要让评委看到屏幕上的真实证据需求条款演示步骤期望结果截图证据评委关注点时间不可重叠1. A用户预约“会议室A” 09:00-10:002. B用户在同一秒提交相同预约B用户页面显示红色提示“该时段已被【A用户】占用”数据库reservation表仅有1条confirmed记录是否精准定位冲突对象显示A用户而非笼统提示“已占用”状态机驱动1. 查看数据库reservation表找到一条statuscreated的记录2. 手动执行UPDATE reservation SET statusarchived WHERE res_idxxx页面刷新后该预约在“我的预约”列表中消失但reservation_log表中无对应archived操作日志是否阻止非法状态跳转created直跳archived权限隔离1. 普通用户登录打开浏览器开发者工具2. 修改URL为/admin/confirmList.jsp页面显示404或重定向至登录页Network面板可见302跳转是否在Controller层拦截而非仅靠前端隐藏链接冲突熔断1. 管理员在“待确认列表”选中一条预约2. 在另一个Tab中用户取消该预约3. 管理员点击“确认”按钮页面弹出提示“该预约已被取消无法确认”数据库状态仍为cancelled是否在确认前二次校验状态而非仅依赖列表缓存提示答辩前用手机录屏把上述4个场景录成1分钟短视频。评委没耐心看你现场操作但会认真看你的证据。视频命名为验收证据_时间冲突.mp4答辩时直接播放。5.2 并发压力验证用最简工具证明你的系统可靠别信“理论上没问题”。用abApache Bench这种命令行工具3分钟就能证明你的并发防护是否真有效。步骤启动Tomcat确保数据库连接池足够db.properties中maxIdle10打开终端执行# 模拟10个用户各发起5次预约请求共50次-k表示keep-alive复用连接 ab -n 50 -c 10 -p reservation_data.txt -T application/x-www-form-urlencoded http://localhost:8080/reservation其中reservation_data.txt内容为actioncreateroom_id1start_time2024-05-2009%3A00%3A00duration_min60查看ab输出的Failed requests: 0失败请求数为0和Concurrency Level: 10并发级别10登录MySQL执行SELECT COUNT(*) FROM reservation WHERE room_id1 AND statusconfirmed; -- 结果应为1因唯一索引限制而非10 SELECT COUNT(*) FROM reservation_log WHERE actioncreate; -- 结果应为50所有请求都记录了日志证明无丢失评委想看到的你不仅知道SELECT FOR UPDATE还能用标准工具量化它的效果。如果ab报告Failed requests: 12说明你的锁机制或事务边界有漏洞必须现场修复。5.3 答辩高频问题应答话术把“不会”变成“我这样设计”评委最爱问“如果……怎么办”这不是刁难而是考察你的设计深度。以下是6个必问题及应答逻辑不说“我没想到”而说“我这样设计是因为……”问题应答话术核心逻辑证据支撑点Q如果管理员误点了两次“确认”会不会重复发送邮件“不会。confirmReservation()方法在更新状态前会先SELECT当前状态。第二次点击时状态已是confirmed直接抛出BusinessException事务回滚邮件服务根本不会触发。”指向ReservationService.java第XX行if (!pending.equals(current.getStatus()))判断Q用户取消预约后已发的通知怎么撤回“技术上无法撤回已发送的邮件但业务上我们规避了这个问题取消操作发生在通知发送之后且通知内容明确标注‘此预约尚未最终确认’。用户取消后系统不再发送新通知历史通知自然失效。”展示notificationService.sendConfirmationEmailAsync()方法中邮件模板的措辞Q为什么用pending状态而不是直接confirmed“因为会议室预约本质是资源协调需人工干预。pending状态让我们能1在确认前拦截冲突2给管理员留出审核窗口3支持批量确认。如果直接confirmed冲突只能靠事后撤销用户体验更差。”对比演示pending流程用户提交→管理员列表→确认vs 直接confirmed用户提交即占用QMySQL的REPEATABLE READ能防止幻读吗你们怎么处理“REPEATABLE READ在MySQL中通过MVCC避免幻读但我们的SELECT ... FOR UPDATE进一步加锁确保查询结果集稳定。更重要的是我们用唯一索引业务校验双保险幻读即使发生也会被后续的INSERT唯一约束拦截。”指向数据库SHOW CREATE TABLE reservation输出中的uk_room_time索引Q如果服务器宕机事务中的预约数据会丢失吗“不会。MySQL的InnoDB引擎有redo log事务提交前日志已刷盘。只要innodb_flush_log_at_trx_commit1默认值宕机后重启能通过日志恢复未完成事务。”展示my.cnf中innodb_flush_log_at_trx_commit1配置Q这个系统能支撑1000人同时预约吗“单机TomcatMySQL在合理配置下QPS 50-100是可靠的。如果需要更高并发我会1加Redis缓存热门会议室列表2用消息队列削峰3读写分离。但课程设计的目标是理解核心逻辑而非架构扩展。”承认局限但给出可落地的演进路径而非画大饼从那以后我每次带学生做毕设都会强制他们在答辩前完成三件事1录好4个核心验收视频2用ab跑通并发测试并截图3把这6个问题的答案写在便利贴上贴在显示器边框。不是为了背答案而是让设计逻辑刻进肌肉记忆——当评委问“为什么”你脱口而出的不是“因为老师说要这样”而是“因为这里有个时间窗口必须用行锁堵住”。希望帮到你。本文还有配套的精品资源点击获取