微信小程序医疗挂号系统架构设计与高并发实践

1. 项目背景与核心价值

作为一名经历过多次医疗信息化项目实战的开发者，我深知传统挂号方式的痛点：患者需要清晨排队、医院管理效率低下、号源分配不公等问题长期存在。去年参与某三甲医院预约系统改造时，我们通过微信小程序将挂号预约率从35%提升至82%，患者平均等待时间缩短了68分钟。

微信小程序作为载体具有天然优势：

• 零安装成本：患者无需下载APP，扫码即用
• 高触达率：依托微信12亿月活用户，推广成本极低
• 开发效率：uniapp框架可实现一次开发多端发布
• 服务闭环：完美整合微信支付、消息通知等核心能力

2. 系统架构设计解析

2.1 技术栈选型决策

后端方案对比：

选择Spring Boot的核心考量：

1. 医疗系统对事务一致性要求高，JPA+Hibernate提供完善的事务管理
2. 需要与医院HIS系统对接，Java的WebService支持更成熟
3. 后期可能对接医保平台，Java的安全生态更完善

数据库设计要点：

sql复制CREATE TABLE `appointment` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `patient_id` varchar(32) NOT NULL COMMENT '关联患者',
  `doctor_id` varchar(32) NOT NULL COMMENT '关联医生',
  `schedule_id` varchar(32) NOT NULL COMMENT '排班ID',
  `status` tinyint NOT NULL DEFAULT '0' COMMENT '0-待支付 1-已预约 2-已取消',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_schedule_patient` (`schedule_id`,`patient_id`) COMMENT '防止重复预约'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关键设计：在预约表建立(schedule_id, patient_id)唯一索引，这是经过实际业务验证的必要约束。某医院系统曾因缺失此约束导致单用户重复占用同一号源。

2.2 高并发场景应对

挂号系统必须考虑秒杀场景（如专家号放出时），我们采用三级防护：

1. 前端防抖：小程序按钮提交后禁用3秒
2. 中间层：Redis分布式锁 + Lua原子脚本

lua复制-- KEYS[1] 排班ID
-- ARGV[1] 用户ID
-- 返回1表示成功
if redis.call('GET', 'lock:'..KEYS[1]) then
    return 0
end
redis.call('SET', 'lock:'..KE