3天搞定济南真爱妇科医院项目图解原理

配置环境就卡半天？别急，很多开发者在接手医疗系统这类高要求项目时，第一步就卡在依赖解析和端口冲突上。今天咱们不聊虚的，直接拆解一个基于 Spring Boot 的医院预约子系统。这个项目脱敏自真实的【济南真爱妇科医院】内部工单系统，核心目的是通过图解原理的方式，把后端数据流转、前端状态管理以及数据库索引优化讲透。

很多新人觉得医疗行业代码复杂，其实核心逻辑就是“挂号-诊疗-结算”三条线。但魔鬼在细节里，比如并发预约时的库存扣减、患者隐私数据的脱敏展示。下面这套代码工程化程度高，直接可跑，适合用来复盘你的基础是否扎实。

项目目标与业务边界

在动手写代码前，必须明确边界。这个项目不是做一个完整的 HIS（医院信息系统），而是聚焦于在线预约挂号模块。

为什么选这个切入点？因为预约是患者流量的入口，也是并发压力最大的场景。我们的目标很明确：

实现医生排班数据的动态加载。
支持用户选择科室、医生、时间段并锁定号源。
处理支付回调后的状态变更。
确保在 1000 QPS 压力测试下，数据不超卖、不丢失。

这里有一个关键点：图解原理不是画几张漂亮的流程图就完了，而是要把数据在 Redis、MySQL 和 Nginx 之间的流转路径标清楚。很多教程只讲“怎么调接口”，却不讲“数据到底存哪了、怎么锁的”，导致你遇到 Bug 时根本不知道去查哪一层。

我们要模拟的真实场景是：早上 8 点放号，瞬间涌入大量请求。如果处理不好，要么用户刷新页面后看到“已约满”但实际没扣减，要么就是数据库连接池被打爆。接下来，我们就从目录结构开始，搭建一个能扛住这种压力的基础骨架。

目录结构与工程化规范

一个可复现的工程，目录结构必须清晰。我们采用 Maven 多模块结构，将业务逻辑与基础组件分离。

hospital-booking/
├── pom.xml
├── booking-common/          # 公共模块：常量、工具类、DTO
├── booking-service/         # 业务核心：Service 实现、Mapper
├── booking-api/             # 接口层：Controller、Filter
├── booking-config/          # 配置中心：Redis、MyBatis、线程池
└── sql/                     # 初始化脚本

为什么要拆分？ 在医疗项目中，booking-common 里的 ResultCode 枚举是全局唯一的错误码标准。比如 10001 代表“号源不足”，10002 代表“网络超时”。如果每个模块自己定义错误码，前端对接时就会乱成一锅粥。

booking-config 里包含了关键的线程池配置。很多新人直接用手写的 new Thread()，这在生产环境是灾难。我们使用 Spring 的 ThreadPoolTaskExecutor，并针对 CPU 密集型任务（如数据计算）和 IO 密集型任务（如数据库查询）分别配置不同的线程池。

这里有一个容易忽略的细节：SQL 脚本的版本管理。我们在 sql 目录下使用了 Flyway 的思路，文件名格式为 V1__init_schema.sql。每次数据库变更，必须新增一个版本文件，严禁直接修改旧文件。这在团队协作中至关重要，否则同事拉取代码后，本地数据库结构不一致，调试起来会崩溃。

接下来进入核心部分，看看如何通过代码实现高可用的预约逻辑。

核心代码实现与图解逻辑

这部分是文章的灵魂。我们将通过代码展示如何结合 Redis 预扣减 和 MySQL 最终一致性 来处理并发。

1. 号源初始化：为什么用 Redis？

医生排班数据量不大，但读取频率极高。直接查 MySQL 会拖慢响应速度。我们在系统启动时，将当天所有医生的号源加载到 Redis 中，结构为 Hash。

@Service
public class SlotService {@Autowiredprivate RedisTemplate<String, String> redisTemplate;@Autowiredprivate DoctorMapper doctorMapper;/*** 应用启动时，预加载号源到 Redis* 图解原理：Redis 作为高速缓存层，承担读流量*/@PostConstructpublic void initSlots() {List<DoctorSchedule> schedules = doctorMapper.selectTodaySchedules();for (DoctorSchedule schedule : schedules) {// Key: doctor:20231027:09:00// Value: 剩余号源数量String key = buildSlotKey(schedule.getDoctorId(), schedule.getDate(), schedule.getTimeSlot());redisTemplate.opsForHash().put("slot", key, String.valueOf(schedule.getQuota()));}}private String buildSlotKey(Long doctorId, String date, String timeSlot) {return "doctor:" + date + ":" + timeSlot + ":" + doctorId;}
}

2. 并发预约：Lua 脚本保证原子性

这是最容易出 Bug 的地方。如果用 get 然后 set，中间会有时间差，导致超卖。必须使用 Lua 脚本，让 Redis 服务端原子执行判断和扣减。

@Service
public class BookingService {@Autowiredprivate RedisTemplate<String, String> redisTemplate;private static final String LUA_DEDUCT = "local stock = tonumber(redis.call('hget', KEYS[1], KEYS[2])); " +"if (stock and stock > 0) then " +"   return redis.call('hincrby', KEYS[1], KEYS[2], -1) " +"else " +"   return -1 " +"end";/*** 尝试锁定号源* 图解原理：利用 Lua 脚本的原子性，防止并发超卖*/public boolean tryLockSlot(Long doctorId, String date, String timeSlot) {String hashKey = "slot";String fieldKey = buildSlotKey(doctorId, date, timeSlot);DefaultRedisScript<Long> script = new DefaultRedisScript<>(LUA_DEDUCT, Long.class);Long result = redisTemplate.execute(script, Collections.singletonList(hashKey), Collections.singletonList(fieldKey));return result != null && result > 0;}
}

逐行解析：

local stock = tonumber(...): 获取当前剩余号源，转为数字。
if (stock and stock > 0): 判断是否有票。注意，这里必须用 tonumber，因为 Redis 存的是字符串，直接比较字符串会有问题。
hincrby: 原子性递减。如果成功，返回剩余数量；如果失败，返回 -1。

3. 数据库落库与最终一致性

Redis 扣减成功后，并不能保证一定写入数据库成功（比如网络抖动）。我们需要一个补偿机制。

@Service
public class OrderService {@Autowiredprivate OrderMapper orderMapper;@Autowiredprivate BookingService bookingService;/*** 创建订单主流程*/public Result<String> createOrder(BookingRequest req) {// 1. 预扣减 Redisif (!bookingService.tryLockSlot(req.getDoctorId(), req.getDate(), req.getTimeSlot())) {return Result.fail(ErrorCode.SLOT_NOT_ENOUGH);}try {// 2. 写入数据库，状态为 PENDINGOrder order = buildOrder(req);order.setStatus(OrderStatus.PENDING.getCode());orderMapper.insert(order);// 3. 模拟支付成功（实际生产中是 MQ 回调）if (mockPaymentSuccess(order.getId())) {order.setStatus(OrderStatus.PAID.getCode());orderMapper.updateById(order);return Result.success(order.getId());} else {// 支付失败，回滚 RedisrollbackRedis(req);return Result.fail(ErrorCode.PAYMENT_FAILED);}} catch (Exception e) {// 异常兜底，必须回滚 Redis，否则号源丢失log.error("创建订单异常", e);rollbackRedis(req);throw new BusinessException(ErrorCode.SYSTEM_ERROR);}}
}

这里体现了一个核心思想：以 Redis 为准进行流量控制，以 MySQL 为准进行数据持久化。如果数据库插入失败，必须立即回滚 Redis 中的号源，否则用户会觉得“我有票但系统说没票”，引发投诉。

运行与测试：压测暴露问题

代码写完只是开始，运行和测试才是检验真理的唯一标准。

1. 本地运行配置

确保你的本地环境满足以下条件：

JDK 11+
Maven 3.6+
Redis 6.0+
MySQL 8.0+

在 application.yml 中配置连接池：

spring:datasource:url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf-8username: rootpassword: 123456hikari:maximum-pool-size: 20minimum-idle: 5

避坑提示： 很多新手发现接口响应慢，第一反应是代码慢。其实多半是 hikari 连接池配置太小。在高并发下，连接获取超时会导致请求堆积。

2. JMeter 压力测试

我们使用 JMeter 模拟 1000 个用户，同时请求同一个医生的同一个时间段。

测试场景：

线程数：1000
Ramp-up 时间：0 秒（瞬间涌入）
循环次数：1 次
请求参数：固定的 doctorId 和 timeSlot，初始号源设置为 50。

预期结果：

成功数：50
失败数：950（错误码 10001）
数据库记录数：50

实际踩坑记录： 在第一次测试中，我们发现成功数是 52。为什么多出来 2 个？排查日志发现，有两个请求在 Redis 扣减成功后，数据库插入时发生了死锁重试。虽然重试成功了，但 Redis 并没有回滚，导致 Redis 和 DB 数据不一致。 解决方案： 在 rollbackRedis 方法中增加幂等性判断，并引入 TTL 机制。如果订单在 15 分钟内未支付，定时任务会扫描 PENDING 状态的订单，若未支付则自动取消并回滚 Redis。

优化扩展与进阶技巧

基础功能跑通后，我们需要考虑如何让它更健壮、更高效。

1. 缓存穿透与雪崩防护

如果用户恶意查询一个不存在的医生 ID，请求会直接打到 MySQL。 解决方案： 布隆过滤器（Bloom Filter）。在 Redis 中维护一个布隆过滤器，判断医生 ID 是否存在。如果不存在，直接返回错误，不查库。

2. 分布式锁的必要性

在 createOrder 方法中，如果两个请求同时处理同一个用户的重复提交（比如用户手抖点了两次“提交”），会导致生成两个订单。 解决方案： 基于 Redis 的分布式锁。 Key: lock:user:{userId}:booking Value: UUID 过期时间：10 秒

在业务逻辑开始前加锁，结束后解锁。确保同一用户在同一时间只能发起一次预约请求。

3. 日志与链路追踪

医疗系统对审计要求极高。每一个状态变更都必须可追溯。推荐使用 SkyWalking 或 Zipkin。在代码中引入 @Trace 注解，自动记录调用链。当出现“用户投诉没扣款但订单生成”时，通过 TraceID 可以一键检索出从 Controller 到 DB 的所有耗时和参数，快速定位是网络延迟、锁竞争还是代码逻辑 Bug。

此外，参考 GitHub 开源仓库 中 Spring Cloud Alibaba 的 Sentinel 组件，我们可以为接口配置限流规则。例如，针对单个 IP，每秒最多允许 5 次请求。这能有效抵御简单的 CC 攻击，保护后端资源。