SpringBoot重构线上就医咨询系统：分时段挂号与并发控制实战

我去年接手了一个线上就医咨询系统的重构，项目代号内部一直叫“1c3d7t79”，就是标题里那串字符。它是一个典型的医疗互联网应用，核心模块包括在线问诊、分时段挂号、药品商城，后端全部跑在 SpringBoot 上。重构之前系统结构非常乱，挂号、问诊、购药混在一个服务里，代码耦合严重，线上问题频出。这次从架构到实现都重来了一遍，过程中踩了不少坑，这篇文章把整个项目的设计思路、核心模块实现、关键技术坑一条条列出来，给要做类似系统的同学做个参考。

先说结论：SpringBoot 做这类业务系统完全够用，关键是模块边界要清晰、分时段号源扣减要做好并发控制、问诊和开药流程要闭环。文章会比较长，涉及代码的部分我尽量贴出可运行的核心片段，最后一部分是真实踩坑记录，建议读完正文后直接跳到那里看，能帮你少走很多弯路。

1. 先想清楚再写代码：系统边界与模块划分

做医疗类系统最忌讳一上来就写接口。挂号、问诊、药品商城虽然看起来是一套业务流程，但它们的数据模型差异非常大：挂号关心的是排班和号源库存，问诊关心的是医患会话和消息流转，商城关心的是药品目录和订单状态。如果一开始不把边界想清楚，后面每加一个需求都要在同一个 Controller 里塞代码，最后必然变成一团乱麻。

1.1 “大单体 + 模块化”而不是一上来就拆微服务

很多同学看到这种项目第一反应是：我要用微服务。但我个人强烈建议，中小规模应用别直接上微服务。线上就医咨询系统虽然模块多，但业务量级在没有爆发式增长前，一个大单体加上清晰的 Maven 多模块结构，比微服务轻松十倍。微服务的好处是独立部署和故障隔离，坏处是分布式事务、跨服务调用排查、运维复杂度都会直线上升。

我当时采用的结构是单应用工程，但在包结构上做了严格划分。每个业务域是一个独立的 Java package，domain、service、controller、mapper 分层整齐，模块之间只允许通过 service 接口通信。

text复制com.hospital.gateway
├── consult          # 在线问诊模块
│   ├── controller
│   ├── domain
│   ├── service
│   └── mapper
├── registration     # 挂号模块
├── pharmacy         # 药品商城模块
├── payment          # 支付与订单模块
├── notification     # 消息通知模块
└── common           # 通用工具、配置、异常处理

有人会问，模块之间如果互相调用怎么办，比如问诊结束后医生直接开药，还需要挂号记录？我的做法是：模块间横向调用通过 service 接口，避免跨模块直接查对方表。比如问诊模块需要用药建议，它会调用 pharmacy 模块暴露的 PrescriptionService，由 pharmacy 自己管理处方药品库存。

1.2 核心领域模型怎么抽？先把“人、单、时”三个维度定下来

医疗系统里数据模型的核心不是“表有多少张”，而是三类信息你怎么建模：

• 人：患者、医生、管理员，三种角色权限不同，档案信息也不同。我把患者、医生都放入一个 user 体系，角色字段区分，但档案表分开存，避免用户表字段膨胀。
• 单：挂号单、问诊单、药品订单、处方单，这几个“单”是业务流转的核心载体。每个单都有状态字段，状态流转必须走状态机，不允许随意 update。
• 时：分时段挂号最重要的就是“时间”这个维度。排班表、号源表、时段表，三者缺一不可。后面我会专门讲分时段的表设计。

不要用一个万能 JSON 字段去存所有扩展信息。比如医生排班可能临时加号、停诊，就单独建 schedule 表和号源表，宁可多两张表也不要把排班逻辑塞到挂号订单的备注字段里。我在旧系统里见过把停诊原因放在 order.remark 的做法，统计时简直灾难。

1.3 为什么选 SpringBoot 而不是 Spring Cloud 或 Solon

技术选型上，SpringBoot 是目前 Java 后端事实标准，生态成熟度没有任何对手。热搜词里很多人问 Solon、问 SpringBoot 新版本，但在这个项目里我坚持用 SpringBoot 2.7.18 + JDK 1.8。为什么？因为这个组合经过大量生产验证，网上踩坑资料最多，且兼容性最稳。SpringBoot 3.x 要求 JDK 17，虽然性能更好，但很多老库的兼容还不到位，医疗系统周边对接的医保接口、第三方支付 SDK 经常是 JDK 8 编译的，盲目上新版本只会给自己挖坑。

2. 技术选型解析：SpringBoot 版本、持久层、认证与工作流

关于技术选型，我单独抽一大部分出来详细讲。热搜里“springboot版本太高”“springboot 2.7.18”“springboot自动装配原理”这些词说明很多人卡在选型上了，我结合这个项目的实际场景说说最终方案和各方案的取舍。

2.1 SpringBoot 与 JDK 版本的最佳组合：2.7.18 是个过渡精品

SpringBoot 2.7.18 是 2.x 系列的最终维护版本，兼容 JDK 8 到 JDK 21，社区支持结束日期也拉长到了 2025 年以后。对于企业级项目来说，它不是最“新”的，但一定是最“稳”的。SpringBoot 3.x 虽然已经成熟，但如果你团队里都是刚从学校出来、只学过 JDK 1.8 的成员，直接上 JDK 17 需要额外的学习成本。

热搜词里还有“springboot 循环依赖”，这一点我建议：如果项目刚起步，根本不建议开循环依赖，虽然 SpringBoot 2.6 起默认禁止循环依赖，你强行配置开启也能跑，但这是埋雷。我重构时把模块边界理清楚，service 之间单向调用，循环依赖自然就不存在了。

2.2 持久层框架：MyBatis-Plus 还是 Spring Data JPA

挂号、商城这种系统，查询条件变化频繁，MyBatis 的灵活性比 JPA 高不少。我最终还是选了 MyBatis-Plus，理由有三个：自带分页插件、代码生成器可以快速生成实体和 Mapper、QueryWrapper 能够应付大部分动态查询而不用写 XML。

热点词里大量关于“springboot整合mybatis”的搜索，说明这是最主流的做法。我建议配置上注意两点：

• mapper.xml 扫描路径最好用 classpath*:mapper/**/*.xml，避免多模块时漏扫。
• 逻辑删除字段做成全局配置，所有表统一叫 deleted，统一为 Integer 类型，这样 MyBatis-Plus 的 @TableLogic 能够全局生效。

分页查询建议直接用 MyBatis-Plus 的 Page，但大数据量深度分页时还是要改成基于 ID 的游标分页。挂号记录历史表到了十几万条以后，深分页慢得离谱。

2.3 认证与接口安全：Spring Security + JWT 的正确配合方式

线上问诊系统涉及用户隐私，认证这块绝对不能随便写个拦截器就糊弄过去。我采取的是 Spring Security + JWT 方案，JWT 无状态认证适合接口服务，但要注意 token 主动失效的问题。

我的做法是双 Token 机制：

热搜里“springboot jwt 放开swagger”也是常见问题。注意 Spring Security 默认把所有请求拦截了，Swagger 静态资源必须放行。配置方式是把 /swagger-ui/**, /v3/api-docs/**, /webjars/** 加入 permitAll 列表。同时生产环境记得把 swagger 关闭或用接口文档平台代替，暴露在线文档很容易被恶意扫描。

权限控制上需要三套角色：PATIENT、DOCTOR、ADMIN。细粒度授权要用注解 @PreAuthorize，比如：

java复制@PreAuthorize("hasAnyRole('DOCTOR', 'ADMIN')")
@PostMapping("/schedules")
public Result createSchedule(@RequestBody ScheduleDTO dto) {
    return Result.success(scheduleService.create(dto));
}

这样患者角色永远无法创建排班，开发时不用每次都担心 Controller 里漏判断角色。

2.4 工作流引擎要不要用：Flowable 在项目里的合理位置

热搜词里几次出现“springboot使用flowable”和“flowable整合springboot实战”，说明不少人对工作流引擎有兴趣。在这个系统里我确实用了 Flowable，但用得非常克制。

我把它用在了“审方流程”。医生在问诊结束后给患者开药，处方单需要经过药师审核才能推送到药品商城。这个流程天然适合 Flowable：医生提交审方申请 -> 系统自动判断是否为处方药 -> 普通药品直接放行 -> 处方药进入药师人工审核队列 -> 审核通过后生成可支付订单。

不建议把挂号流程也用 Flowable 做，挂号流程太简单且对性能要求高，用流程引擎会白白增加表数量和复杂度。Flowable 的引入是为了应对以后审方规则变化，比如增加多人会审、超时自动提醒这类业务。

3. 分时段挂号：整个系统技术含量最高的模块

分时段挂号是标题里最核心的功能，也是最容易做烂的模块。它的难点不在 CRUD，在于“号源库存扣减”和“排班规则”这两个点，任何一个设计失误都会导致两种情况：一是患者同时抢号成功，系统超卖；二是明明有号，患者却刷不出来，医生排班显示异常。

3.1 号源库存设计：排班表 + 时段模板 + 号源明细三张表

我先交代数据模型。医生排班围绕时段展开，分三步设计：

定期生成排班：管理员或医生先定义“每周出诊计划”（星期几、上午还是下午、每时段多少人），系统按周生成具体排班和号源。表结构如下：

schedule（排班表）

time_slot_template(时段模板表)：每个排班可以关联多个模板时段，这里的设计符合分时段。

注意：时段长度应设置为 10-30 分钟。以 30 分钟为一个时段，半天出诊就可以分为 8 个时段。每个时段分配固定号源数，比如初诊 3 个，复诊 5 个。总号数不摊到全天而是摊到每个时段，这样“分时段”才有意义，患者选择时段后看到的号源是那个时段的剩余量。

3.2 号源扣减：从数据库乐观锁到 Redis 预扣

抢号场景有几个特征：瞬时并发集中在某个放号时间点，写多读多，且操作必须幂等。最简单可靠的方式是数据库乐观锁更新：

sql复制UPDATE schedule
SET remain_slots = remain_slots - 1
WHERE id = #{scheduleId}
  AND remain_slots > 0;

这行 SQL 的核心是 remain_slots > 0 条件，更新受影响行数为 0 说明号源被抢完了。

但在实际运行中，如果所有请求都打 MySQL，高峰期连接池分分钟被占满，数据库 CPU 上涨明显。于是我把方案改成 Redis 预扣 + 异步落库：

1. 医生排班生成时，把每个时段的剩余号源初始化进 Redis，key 设计为 reg:slot:{scheduleId}:{timeSlotId}。
2. 用户提交挂号，先用 Redis 的 DECR 原子操作扣减，返回值为负则说明没号。
3. 号源扣减成功，将挂号信息写入 RabbitMQ 或本地线程池异步落库。
4. 最终以数据库更新结果为准，如果落库失败，用 Lua 脚本把 Redis 号源回补。

这个方法的好处是 Redis 的 QPS 能支撑很高并发，数据库只在落库和异步更新时承受压力。唯一要小心的就是 Redis 挂了会导致号源扣减不可用，所以我会对缓存操作做降级，如果 Redis 连接失败自动切换为数据库扣减。

3.3 一个容易被忽略的坑：同一个患者不能重复挂同一时段

首次上线时我忘了加幂等校验。后来测试发现，用户在网络卡顿时连点三次“确认挂号”，由于每个请求都通过了号源扣减，系统生成了 3 张挂号单。虽然号源不会超卖，但用户被重复收费，这是更严重的问题。

我的解决方式分两层：

• 前端做按钮 loading，防止重复提交，但这不是可靠屏障。
• 后端在用户提交挂号时加分布式锁 Redis SETNX，key 设计为 lock:patient:{userId}:{scheduleId}:{date}，锁过期时间 30 秒，请求进入时先尝试加锁，加锁失败直接返回“操作太频繁”。

另外，数据库层面给挂号记录表加唯一索引，patient_id + schedule_id + time_slot_id。三个字段同时相同就无法插入，这是兜底。两个层叠加起来，重复挂号问题才算彻底解决。

3.4 停诊与退号：反向补偿的流程不能少

系统要考虑医生临时停诊。停诊时不能直接删排班，应该把排班状态置为停诊，然后给已预约患者推送消息通知，同时自动释放号源并为患者办理退费。

我在实现时写了一个定时任务，每分钟扫描停诊排班下的挂号单，对未就诊的挂号单批量更新状态为“已退号”，并调用支付平台退款接口。这个定时任务用 SpringBoot 自带的 @Scheduled 就够了，不需要引入 Quartz 这么重的东西。

为什么不用 Quartz？热搜里很多人问 springboot quartz，但对这个场景，每分钟一次的简单轮询完全够用，@Scheduled 配置 cron 表达式即可。引入 Quartz 会增加持久化 job 的管理成本，医疗系统里的定时任务通常数量少但准确性要求高，等到真有复杂调度需求再上 XXL-Job 也不迟。

4. 线上问诊与开药：让医患沟通形成业务闭环

线上就医咨询不是聊天工具，它必须服务于医疗流程。问诊结束后医生能不能直接开处方？处方药品怎么流转到商城？这些环节如果不打通，咨询就是空中楼阁。

4.1 问诊会话状态机与超时释放

问诊会话状态我定义了四个：WAITING(等待医生接入)、IN_PROGRESS(进行中)、FINISHED(已完成)、CANCELLED(已取消)。每个状态允许的迁移：

这里要特别注意，状态更新不能散落写在业务代码里，最好用状态机或者至少写在 service 层统一判断。如果每个 Controller 都写一段 update status，后面加需求很容易漏掉某个分支，导致会话卡在已结束还能继续发消息。

关于消息推送，问诊咨询的实时性要求比较高，WebSocket 是标配。我在项目里使用 SpringBoot 自带的 WebSocket 模块，通过 token 解析用户身份后绑定 session。

java复制@Component
public class ChatWebSocketHandler extends TextWebSocketHandler {
    private static final Map<Long, WebSocketSession> SESSION_POOL = new ConcurrentHashMap<>();

    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
        // 消息格式：{ "type": "chat", "consultId": 123, "content": "..." }
        ChatMessage chatMessage = JSON.parseObject(message.getPayload(), ChatMessage.class);
        // 保存消息并推送
        consultService.sendMessageToSession(chatMessage);
    }
}

单机部署下 ConcurrentHashMap 够用。如果将来做多实例部署，分布式 WebSocket 需要引入 Redis Pub/Sub 或 MQTT，session 信息要放到 Redis 而不是本地 Map。

4.2 问诊怎么和开药衔接：会诊结束生成待审方订单

问诊结束不是简单的状态置为 FINISHED。医生需要在一个问诊周期内填写诊断结论，然后选择是否给患者开药。开药操作调药品服务生成处方草稿，经过 Flowable 审方流程后转为正式处方，再与商城的订单系统关联。

这里要设计一个 consult_prescription 关联表，把问诊单 ID 和处方单 ID 绑定。后续患者在药品商城购买处方药时，需要选择“关联问诊处方”，系统根据问诊单 ID 查出可用的处方，校验处方状态为已审核且未过期。这个闭环做通之后，患者复诊开药根本不需要重新排队挂号，在线续方就完成了。

5. 药品商城：订单与库存的平稳落地

药品商城和普通商城有区别，核心是药品是特殊商品，除了最基本的 SKU 体系，还要支持处方药核验、拆零包装规则、有效期批次管理。

5.1 药品目录设计与处方药标识

药品表我做成标准 SPU/SKU 模型，一个通用名叫 SPU，不同厂家不同规格叫 SKU。处方药加了一个字段 prescription_flag，0 为非处方药，1 为处方药。结算下单时如果购物车中有处方药，必须先判定是否有有效处方，没有则拦截订单。

5.2 购物车与订单防重

药品商城最容易出现的并发问题有两个：重复下单和下单后库存扣减失败。我通过生成订单号前先查购物车的操作状态，再通过唯一订单流水号 order_no 加唯一索引。用户点击提交订单，第一步是创建状态为 UNPAID 的订单记录，订单号通过 Redis INCR 生成；第二步扣减库存，库存不足时直接取消订单并回滚。

库存扣减用前面类似的方法。但药品商城库存准确度要求更高，涉及先进先出和批次有效期，所以我没有使用 Redis 预扣，而是直接面向数据库乐观锁更新。原因很简单，药品商城的并发量远没有挂号高，但每笔订单涉及的库存和批次逻辑复杂，保证最终一致更重要。

5.3 售后与自动对账

退款流程对接支付平台，患者订单未发货时可以系统自动退款，已发货则需要人工审核。这一步我用一个补偿任务扫描退款状态，定时调用支付网关查询退款结果，避免回调丢失导致用户资金长时间未退回。

6. 高频问题汇总与故障排查实录

项目上线后我会持续收到各种各样的运行问题报告。这一部分把搜索词里高频的问题和线上实际发生过的故障做一个汇总，每个问题我给出直接可用的排查思路，不是为了凑内容，是真一个个遇到过。

6.1 事务失效：@Transactional 只在 61 行代码里起作用

我写过一次非常隐蔽的 bug。同一个类中 A 方法调用 B 方法，A 没有加 @Transactional，B 加了但实际不生效。Spring 的事务是基于 AOP 代理的，类内部方法调用走的是 this 引用，不会经过代理。解决方法是把 B 方法移到另一个 Service 类，或者在 A 方法上强制加 @Transactional 并让 B 方法通过注入的自身代理调用。

6.2 Redis 连接断开后为什么会雪崩

上线初期 Redis 哨兵配置没做连接池参数调优。某天活动放出 2000 个专家号，请求量瞬间上来，Redis 客户端连接池默认 8 个连接全部打满，请求排队导致接口超时，连锁反应是数据库连接也会被打满。

热点词里有人搜“springboot redis哨兵”，我建议配置上特别注意：

yaml复制spring:
  data:
    redis:
      timeout: 3000ms
      jedis:
        pool:
          max-active: 50
          max-idle: 20
          min-idle: 5
          max-wait: 3000ms

max-active 从默认 8 改成 50，min-idle 设置 5，确保高并发时有足够的连接，同时要对所有 Redis 操作做降级逻辑，比如判断返回值 null 时直接走数据库查询。

6.3 RocketMQ 批量消费场景下的重复扣减

项目中药品订单状态变更使用 RocketMQ 进行异步通知。热搜里有“springboot下rocketmq批量消费”，很多人在批量消费场景没处理好幂等。消费者的 @RocketMQMessageListener 默认一次拉取一批消息，如果处理第 5 条消息时抛异常，这批消息会按失败重试，前面处理成功的那几条消息对应的事件就会重复执行。

我的经验是消费者方法必须幂等。比如更新订单状态，更新前先校验当前状态是否允许迁移。不能加 where id=#{id} 的乐观锁，重试时受影响行数为 0 则直接忽略。这才是治本的办法。

6.4 定时任务的“双触发器”陷阱

用 @Scheduled(cron = "0 0 2 * * ?") 跑每日对账，如果有多个实例部署，到点会触发多个对账任务。我在单机阶段没注意这个问题，后来加了集群部署后每天对账跑了两次，调用支付平台退款接口时产生重复退款。解决方案加 ShedLock 分布式锁，或把所有定时任务集中到一台机器的执行器上。

7. 项目部署与开发环境的一些实操建议

开发阶段我在 window 本地用 IDEA + Docker Desktop 跑 MySQL 和 Redis，部署阶段打包到 Linux 服务器。关于“springboot jdk1.8打包到docker desktop”，很多新手会卡在打包这一步，核心是把 Dockerfile 写对。

dockerfile复制FROM openjdk:8-jre-alpine
WORKDIR /app
COPY target/hospital-server.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar", "--spring.profiles.active=prod"]

打包时注意：如果本地是 macOS ARM 芯片，直接构建 openjdk:8-jre-alpine 可能架构不对导致启动报错，用 --platform=linux/amd64 重新构建镜像。

配置分离用 Spring Boot Profile，把开发、测试、生产环境分开配置。生产环境的配置文件不要打包进 jar，用外部配置文件加载，避免数据库密码被反编译拿到。

8. 在线问诊的数据表细节：别让消息表成为性能陷阱

在线问诊咨询的消息记录是增长最快的表，一天可能产生几万条消息。第一次设计时我把所有历史消息都放进一张表，半年后这张表超过 2000 万行，查询聊天记录时数据库明显变慢。

后来我采取两个优化方案：

1. 消息表按月份做分表，或者至少要做归档表，用定时任务把 3 个月前的历史消息迁移到归档库。
2. 聊天记录读取不要求强一致性，读取时优先查 Redis，Redis 只存最近 100 条消息，如果未命中再查数据库，为数据库做缓存压力分流。

另外问诊的会话记录会涉及患者隐私保护，建议密文存储部分敏感字段（如患者病情描述），数据库权限也要严格控制。对外的系统管理员不能直接允许明文的敏感信息导出，至少要做好脱敏处理。

9. 分时段挂号算法衍生：支持批量锁号与定时释放

上面讲了基本的号源扣减逻辑，还有一种是预约聚合场景。比如某个企业做团体体检预约，需要一次性锁定多个时段的号源。如果普通用户和团购用户共用一套扣减逻辑，很容易把号源锁死。

我的做法是对号源表增加一个 lock_source 字段，区分“线上散客号源”和“团体号源”。锁定时段号源先做批量预占，团体支付完成前保持锁定，订单超时未支付则自动释放。

批量锁号用 Lua 脚本实现 Redis 原子性：

lua复制local key = KEYS[1]
local qty = tonumber(ARGV[1])
local remain = tonumber(redis.call('get', key) or '0')
redis.call('set', key, remain - qty)
return remain - qty

这段脚本的好处是几个号源的扣减在 Redis 端一次性完成，不会出现中间状态。如果某个时段剩余不足，整个预占失败，回补其他时段的库存。

10. 药品商城的药品搜索：不要让模糊查询把数据库拖垮

药品商城首页搜索框会自动补全药品名，简单实现是 like 查询，但数据量上来后慢查询基本是必然的。热搜词里提到“hanlp分词在springboot”，也就是想让搜索支持中文分词。

方案有两种。轻量级选择用 MySQL FULLTEXT 索引，中文分词效果比较差；严格选择上 ElasticSearch。作为博主我给中间建议：如果预算允许，直接引入 ElasticSearch 处理药品搜索，如果不想引入重型中间件，先把药品通用名做拼音简码字段，用户输入“ahn”能快速查到“阿莫西林胶囊”这种常见药。

等未来业务规模上来，再考虑用 HanLP 做更专业的查询分析与同义词扩展。

我在项目里的实际选择是用拼音简码方案先顶住日常工作，把 ElasticSearch 的索引同步放到后续的二期计划里。医疗搜药品不比电商搜衣服，大多问的是“这个药怎么吃”“有没有别的药可以替代”，真正依赖搜索的场景比想象中少。

11. 关于 SpringBoot 自动装配原理给这个项目的启示

最后补充一个可能和技术细节关系不大但能优化团队协作的认知维度：SpringBoot 的自动装配原理。

当一个项目里的 starter 超过 10 个，你就要理解 @EnableAutoConfiguration 是如何选择性地创建 Bean 的。遇到“Redis 缓存不生效”“MyBatis Mapper 扫描不到”这类问题，不要盲改配置，而是先理解自动装配的条件注解。

热点里频繁搜“springboot自动装配原理”和“springboot自动配置原理”。在我的实际项目里，这类问题占到线上 bug 的三分之一，很多同学遇到 BeanNotDefinedException 就加 @ComponentScan 通配，结果把其他包也扫了，出现鸡尾酒式启动错误。

建议处理方式是：牢记自动装配基于 @ConditionalOnMissingBean、@ConditionalOnClass 这些条件。排除某个无法加载的自动配置类，优先使用 exclude 属性，不要把整个包扫描目录换成根目录。

12. 聊聊系统的安全合规与隐私保护问题

做线上就医咨询一定绕不开合规问题。文章里不讨论具体法规条文，但就工程实现分享几个基本动作：

• 传输层强制要求 HTTPS，敏感字段如身份证号在数据库层做加密存储，展示时做掩码。
• 登录接口增加失败次数锁定验证码，防止撞库攻击。
• 越权问题是代码审查重点：患者 A 不能查看患者 B 的问诊记录和处方。每一个暴露 ID 的接口都要校验当前用户对该资源是否有权限，不能只校验登录态。

我当时开发时就在 Controller 层加了一个公共抽象方法：checkResourceOwner(resourceId, ownerId)，所有涉及详情的接口都调这个方法。一开始觉得烦，后来发现这是防止水平越权最朴素也最有效的方式。

13. 一点系统性能压测的经验参考

上线前我对挂号模块、问诊模块和下单接口各做了一轮 Jmeter 压测。挂号接口在 Redis 预扣方案下，单台 4 核 8 G 服务器能扛住约 1200 TPS，数据库扣减方案则只有 300 TPS 左右，相差约 4 倍。

压测过程中发现的瓶颈主要是数据库连接池默认值太小。Spring Boot 默认 HikariCP 最大连接池是 10，对数据库扣减型操作来说远远不够。我调整到了 50，同时把 MySQL 的 max_connections 调整到 500，配合慢查询日志定位到几条漏索引的 SQL 之后，整体性能才算稳定下来。

如果重新让我做一次这个压测，我会提前把 SQL 慢查询开关打开，而不是压测后才发现问题。

14. 后续迭代的两个方向

这个系统目前稳定运行了差不多一年，主体功能没有任何大改。后续迭代我考虑两个方向：

第一个方向是引入更完善的排班算法。现在的排班规则是固定时段模式，但不同科室的就诊平均时长差异很大：皮肤科一个患者可能要 10 分钟，儿科高峰可能只要 5 分钟。根据历史平均就诊时长动态调整号源分配是一个值得做的优化点。

第二个方向是把处方流转做得更深。从线上咨询延伸到处方外配，与线下药店结合取药，让用户端的体验更顺滑。这是一个很大的工程，涉及接口开放平台打造，不是一次迭代能完成的。

在项目里做医疗系统和个人开发者做博客系统最大的差异在于，每一步改动都直接关系患者体验和数据正确性。我个人的体会有三点：分时段挂号的核心不是界面，而是号源并发扣减带来的数据一致性；问诊是业务核心但不是功能核心，整个系统必须围绕“快速获得诊疗服务”这个目标；药品商城如果不能和医生沉淀下来的处方打通，就没有存在的价值。希望这篇文章能帮你把这个项目的坑提前填平。