夏子林1. 项目概述：SpringBoot会议室管理系统开发实录
去年负责公司办公系统升级时，我接手了会议室管理模块的重构任务。传统的手工预约登记方式导致会议室使用率不足35%，而技术部门自研的旧系统又存在并发崩溃的问题。基于SpringBoot 2.7 + Vue 3的全新方案上线后，不仅将会议室利用率提升至78%，还实现了移动端扫码签到、智能冲突检测等实用功能。本文将完整还原这个日均处理300+预约请求的系统实现过程，特别分享在时间冲突算法优化和分布式锁应用上的实战经验。
这个管理系统核心解决三大痛点：
- 可视化预约：通过日历视图直观展示会议室状态
- 智能冲突检测：基于时间重叠算法的自动校验
- 全流程追踪：从预约、审批到使用记录的完整闭环
适合具有SpringBoot基础（熟悉注解开发、MyBatis操作）的开发者参考，源码已通过企业级安全审计（SQL注入/XSS防护等），可直接用于生产环境。项目采用经典的Maven多模块架构，包含meeting-core（核心逻辑）、meeting-web（接口层）、meeting-admin（管理后台）三个子模块。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术架构设计解析
2.1 整体技术栈选型
mermaid复制graph TD
A[前端] -->|Vue3| B(Element Plus)
B --> C[Axios]
D[后端] -->|SpringBoot 2.7| E(MyBatis-Plus)
E --> F[Redis]
F --> G[Quartz]
H[数据库] -->|MySQL 8.0| I[分表策略]
这套组合拳的考量在于：
- MyBatis-Plus vs JPA：选择前者因为公司DBA团队更熟悉SQL优化，且需要处理遗留的复杂查询
- Redis应用场景：
- 分布式锁（Redisson实现）
- 会议室状态缓存（降低数据库压力30%）
- 当日预约排行榜（使用ZSET结构）
- Quartz定时任务：
- 凌晨1点清理过期预约
- 每30分钟同步会议室设备状态
2.2 数据库关键设计
会议室表meeting_room的核心字段：
sql复制CREATE TABLE `meeting_room` (
`id` bigint NOT NULL AUTO_INCREMENT COMMENT '雪花算法ID',
`room_code` varchar(32) NOT NULL COMMENT '会议室编码（如A-101）',
`capacity` int DEFAULT '6' COMMENT '容纳人数',
`equipment` json DEFAULT NULL COMMENT '设备配置（投影/白板等）',
`status` tinyint DEFAULT '1' COMMENT '0-维护中 1-可用',
`version` int DEFAULT '0' COMMENT '乐观锁版本号',
PRIMARY KEY (`id`),
UNIQUE KEY `uk_code` (`room_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
预约记录表meeting_order的特殊处理：
- 按月份分表（order_202307、order_202308）
- 建立联合索引
idx_roomid_time（room_id, start_time, end_time） - 使用状态机模式设计
order_status字段（0-待审核 1-已预约 2-使用中 3-已完成 4-已取消）
3. 核心功能实现细节
3.1 时间冲突检测算法
预约冲突校验是系统的核心难点，我们最终采用时间段重叠算法而非简单的开始时间比较：
java复制public boolean checkTimeConflict(LocalDateTime newStart, LocalDateTime newEnd,
LocalDateTime existStart, LocalDateTime existEnd) {
// 情况1：新预约完全在已有预约之前
// 情况2：新预约完全在已有预约之后
// 情况3：新预约与已有预约重叠
return !(newEnd.isBefore(existStart) || newStart.isAfter(existEnd));
}
实际业务中还需要考虑：
- 提前15分钟入场缓冲期
- 会议最长持续4小时的限制
- 同一部门优先续约策略
3.2 分布式锁实现
高并发场景下使用Redisson的RLock解决超卖问题：
java复制public boolean reserveRoom(Long roomId, Long userId) {
String lockKey = "room_lock:" + roomId;
RLock lock = redissonClient.getLock(lockKey);
try {
// 尝试加锁，最多等待100ms，锁持有时间30s
if (lock.tryLock(100, 30000, TimeUnit.MILLISECONDS)) {
// 1. 查询会议室当前状态
// 2. 执行预约逻辑
// 3. 更新缓存
return true;
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
lock.unlock();
}
return false;
}
3.3 动态权限控制
基于Spring Security的权限方案扩展：
java复制@PreAuthorize("@pms.hasPermission('meeting:reserve')")
@PostMapping("/reserve")
public Result reserve(@Valid @RequestBody ReserveDTO dto) {
// 预约逻辑
}
// 自定义权限校验器
@Component("pms")
public class PermissionService {
public boolean hasPermission(String permission) {
// 获取用户角色
// 查询角色-权限关联表
// 返回校验结果
}
}
4. 典型问题排查实录
4.1 日历视图加载慢
现象：查询本月所有会议室预约数据时，接口响应超过5秒
排查过程：
- 发现没有使用
start_time索引 - EXPLAIN显示全表扫描order_202307
- 存在
OR条件导致索引失效
优化方案：
sql复制-- 原错误写法
SELECT * FROM order_202307
WHERE room_id = 1 OR room_id = 2;
-- 优化为UNION ALL
SELECT * FROM order_202307 WHERE room_id = 1
UNION ALL
SELECT * FROM order_202307 WHERE room_id = 2;
4.2 缓存一致性问题
现象：会议室状态变更后，部分用户仍看到旧状态
解决方案：
- 采用双删策略：
java复制public void updateRoomStatus(Long roomId, Integer status) {
// 1. 删除缓存
redisTemplate.delete("room:" + roomId);
// 2. 更新数据库
meetingRoomMapper.updateStatus(roomId, status);
// 3. 延迟再删（通过消息队列）
delayQueue.add(new CacheDeleteTask("room:" + roomId));
}
- 引入canal监听binlog同步缓存
5. 安全防护实践
5.1 XSS防御方案
针对会议室描述字段的处理：
java复制@Bean
public FilterRegistrationBean xssFilter() {
FilterRegistrationBean registration = new FilterRegistrationBean();
registration.setFilter(new XssFilter());
registration.addUrlPatterns("/*");
registration.setName("xssFilter");
return registration;
}
// 自定义XSS过滤器
public class XssFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
chain.doFilter(new XssHttpServletRequestWrapper((HttpServletRequest) request), response);
}
}
5.2 预约防刷策略
- 滑动窗口限流（Redis实现）：
java复制public boolean isAllowReserve(Long userId) {
String key = "reserve_limit:" + userId;
long now = System.currentTimeMillis();
// 保留最近1小时的记录
redisTemplate.opsForZSet().removeRangeByScore(key, 0, now - 3600000);
// 检查当前数量
long count = redisTemplate.opsForZSet().zCard(key);
if (count >= 5) { // 1小时内不超过5次
return false;
}
redisTemplate.opsForZSet().add(key, String.valueOf(now), now);
return true;
}
6. 前端交互优化技巧
6.1 日历组件性能提升
使用虚拟滚动技术处理大量预约数据：
vue复制<template>
<el-calendar>
<template #dateCell="{ date, data }">
<virtual-scroll :data="getDayMeetings(date)" :item-size="50">
<template #default="{ item }">
<div class="meeting-item">{{ item.title }}</div>
</template>
</virtual-scroll>
</template>
</el-calendar>
</template>
6.2 移动端适配方案
通过CSS媒体查询实现响应式布局：
css复制/* 桌面端 */
.meeting-card {
width: 300px;
}
@media (max-width: 768px) {
/* 平板 */
.meeting-card {
width: 200px;
}
}
@media (max-width: 480px) {
/* 手机 */
.meeting-card {
width: 100%;
}
}
7. 部署与监控
7.1 Docker Compose部署
yaml复制version: '3'
services:
meeting-app:
image: meeting-system:1.0
ports:
- "8080:8080"
depends_on:
- redis
- mysql
environment:
- SPRING_PROFILES_ACTIVE=prod
redis:
image: redis:6
ports:
- "6379:6379"
volumes:
- redis_data:/data
mysql:
image: mysql:8.0
ports:
- "3306:3306"
volumes:
- mysql_data:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=Meeting@123
volumes:
redis_data:
mysql_data:
7.2 Prometheus监控配置
应用暴露的监控端点：
properties复制# application-prod.properties
management.endpoints.web.exposure.include=health,info,prometheus
management.metrics.tags.application=meeting-system
对应的Grafana看板监控指标：
- 会议室预约QPS
- 平均响应时间
- 缓存命中率
- 异常预约请求数
8. 源码结构说明
项目采用标准Maven多模块结构：
code复制meeting-parent
├── meeting-common // 通用工具类
├── meeting-core // 业务核心逻辑
├── meeting-web // REST接口层
├── meeting-admin // 管理后台
└── meeting-gateway // 网关层
关键代码片段位置：
- 冲突检测算法：
meeting-core/src/main/java/com/example/meeting/service/impl/MeetingServiceImpl.java - 权限控制：
meeting-web/src/main/java/com/example/meeting/config/SecurityConfig.java - 缓存策略：
meeting-core/src/main/java/com/example/meeting/cache/MeetingRoomCache.java
在实现过程中最值得分享的是时间冲突算法的优化历程：最初使用简单的开始时间比较，直到出现跨天会议的场景导致逻辑漏洞。后来改为时间段重叠算法后，又发现需要处理时区问题。最终方案是统一转换为UTC时间再比较，这个经验让我深刻意识到时间处理的复杂性。