1. 项目背景与核心需求
医院预约挂号系统是医疗信息化建设中的关键一环，旨在解决传统挂号方式排队时间长、号源分配不均等问题。基于SpringBoot和Vue的前后端分离架构，能够充分发挥Java生态的稳定性和Vue框架的灵活交互优势。
这个系统需要实现的核心功能包括：
- 患者端的在线挂号、取消预约、查询医生排班
- 医生端的号源管理、患者信息查看
- 管理员的科室管理、医生排班设置
- 实时号源状态更新与冲突检测
2. 技术选型解析
2.1 后端技术栈
采用SpringBoot 2.7.x版本作为后端框架，主要考虑因素：
- 自动配置特性可快速集成MyBatis-Plus、Redis等组件
- 内嵌Tomcat简化部署，与医院现有Java环境兼容性好
- 完善的健康检查机制保障系统稳定性
关键依赖配置示例：
xml复制<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.2</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
2.2 前端技术栈
选择Vue3+Element Plus的组合方案：
- 组件化开发便于维护挂号表单、排班表等复杂UI
- Composition API更适合处理预约业务逻辑
- 轻量级框架减少患者端页面加载时间
典型页面结构：
bash复制src/
├── api/ # 接口定义
├── components/ # 公共组件
│ ├── ScheduleTable.vue # 排班表组件
│ └── DoctorCard.vue # 医生卡片
├── stores/ # Pinia状态管理
└── views/ # 页面视图
3. 核心业务实现
3.1 号源管理设计
采用分时段的号池机制：
- 管理员设置医生每周固定排班模板
- 系统每日凌晨自动生成未来7天的号源
- Redis缓存实时号源状态，结构设计：
java复制// 号源缓存Key设计
doctor:{did}:schedule:{date}:am // 上午号源
doctor:{did}:schedule:{date}:pm // 下午号源
// 使用Hash存储每个时段的可预约数
// 字段示例：
// 8:00-8:30 -> 15 (剩余数量)
// 8:30-9:00 -> 15
3.2 预约事务处理
解决高并发下的超卖问题：
- 采用Redis分布式锁保证原子性
- 数据库使用乐观锁控制更新
- 事务处理伪代码：
java复制@Transactional
public boolean makeAppointment(Long scheduleId) {
// 1. 检查号源余量
// 2. 获取分布式锁
// 3. 扣减缓存库存
// 4. 创建预约记录
// 5. 更新数据库余量
// 6. 释放锁
}
4. 关键问题解决方案
4.1 排班冲突检测
医生排班时需要避免：
- 同一时段多科室坐诊
- 休息日安排门诊
- 特殊假期排班
解决方案：
sql复制-- 冲突检测SQL示例
SELECT COUNT(*) FROM doctor_schedule
WHERE doctor_id = ?
AND schedule_date = ?
AND (
(start_time < ? AND end_time > ?)
OR (start_time >= ? AND start_time < ?)
)
4.2 定时任务设计
使用Spring Scheduler处理：
- 每日0点生成新号源
- 每小时清理过期未支付预约
- 凌晨统计前日就诊数据
配置示例：
java复制@Scheduled(cron = "0 0 0 * * ?")
public void generateDailySchedules() {
// 获取所有医生模板
// 生成未来第7天的号源
// 初始化Redis库存
}
5. 安全与性能优化
5.1 防刷单机制
- 患者维度限制：
- 同一医生每日最多预约2次
- 30分钟内取消3次自动加入黑名单
- 接口层面防护：
- 验证码校验
- 滑动条人机验证
- IP频次限制
5.2 缓存策略
采用多级缓存架构：
- 静态数据：Ehcache本地缓存
- 号源数据：Redis集群
- 医生信息：Caffeine缓存
缓存更新策略对比：
| 策略类型 | 适用场景 | 实现复杂度 | 数据一致性 |
|---|---|---|---|
| 定时刷新 | 排班表数据 | 低 | 最终一致 |
| 主动失效 | 号源余量 | 中 | 强一致 |
| 写穿透 | 医生信息 | 高 | 实时一致 |
6. 部署架构建议
推荐采用容器化部署方案：
yaml复制# docker-compose示例
version: '3'
services:
app:
image: hospital-booking:1.0
ports:
- "8080:8080"
depends_on:
- redis
- mysql
redis:
image: redis:6-alpine
ports:
- "6379:6379"
关键监控指标：
- 预约接口平均响应时间(<500ms)
- 号源查询QPS(峰值≥3000)
- 支付超时率(<0.5%)
7. 开发注意事项
-
时间处理陷阱：
- 使用Instant存储时间戳
- 前端显示需考虑时区转换
- 节假日判断使用国家法定假期API
-
医生排班模板的版本控制：
- 保留历史版本便于追溯
- 变更时需同步更新关联号源
-
测试重点：
- 高并发预约场景
- 网络抖动时的支付一致性
- 缓存失效后的降级策略
实际开发中发现，使用Redisson的看门狗机制可以有效解决分布式锁续期问题，避免预约过程中锁过期导致的业务异常。对于三甲医院的场景，建议采用Redis集群方案而非单节点部署。