Spring Boot 3.2 Vue 3 疫苗预约系统高并发预约场景下数据库设计 3 个关键点当疫苗预约系统遇上秒杀级流量数据库瞬间可能成为整个系统的瓶颈。去年某省会城市开放九价HPV疫苗预约时系统在1分钟内涌入超过50万请求——这种场景下传统的CRUD设计模式会直接崩溃。本文将聚焦三个能扛住真实高并发考验的数据库设计策略这些方案在某三甲医院预约系统中实际支撑过单日300万的预约量。1. 表结构设计与索引优化不只是字段规划高并发场景下的表结构设计需要同时考虑数据一致性和查询性能。我们来看一个经过实战检验的疫苗预约核心表设计CREATE TABLE vaccine_appointment ( id bigint NOT NULL COMMENT 雪花算法ID, vaccine_id bigint NOT NULL COMMENT 疫苗ID, time_slot_id bigint NOT NULL COMMENT 时间段ID, user_id bigint NOT NULL COMMENT 用户ID, serial_number varchar(32) NOT NULL COMMENT 预约流水号, status tinyint NOT NULL DEFAULT 0 COMMENT 0-待确认 1-已预约 2-已取消, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY idx_user_vaccine (user_id,vaccine_id), KEY idx_time_slot (time_slot_id), KEY idx_serial (serial_number) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_0900_ai_ci;这个设计有几个关键点值得注意分布式ID使用雪花算法替代自增ID避免分库分表时的ID冲突组合唯一索引通过idx_user_vaccine防止同一用户重复预约同种疫苗乐观锁字段version字段用于后续的并发控制时间戳精确记录创建和更新时间便于后续对账提示在高并发场景下所有时间类型字段都应使用datetime而非timestamp因为后者会受服务器时区影响对于疫苗库存表我们采用分时段库存设计CREATE TABLE vaccine_stock ( id bigint NOT NULL, vaccine_id bigint NOT NULL, time_slot_id bigint NOT NULL, total int NOT NULL COMMENT 总库存, available int NOT NULL COMMENT 可用库存, frozen int NOT NULL DEFAULT 0 COMMENT 冻结库存, PRIMARY KEY (id), UNIQUE KEY idx_vaccine_time (vaccine_id,time_slot_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这种设计将库存细化到每个时间段避免了全局库存的争抢问题。2. Redis库存预扣减毫秒级响应的秘密直接操作数据库处理库存扣减在并发量超过1000TPS时就会遇到性能瓶颈。我们的解决方案是使用Redis进行库存预扣减核心流程如下用户请求进入时先检查本地缓存Guava Cache的频控计数器通过校验后向Redis发送Lua脚本执行原子化扣减扣减成功则生成预订单进入MQ消费者处理MQ消息完成数据库层面的最终预约以下是关键的Redis Lua脚本-- KEYS[1] 库存key -- ARGV[1] 扣减数量 -- 返回1成功0失败 local stock tonumber(redis.call(GET, KEYS[1])) if stock and stock tonumber(ARGV[1]) then return redis.call(DECRBY, KEYS[1], ARGV[1]) else return 0 end在Spring Boot中这样调用public boolean reduceStock(String key, int quantity) { String script 上面lua脚本内容; RedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result redisTemplate.execute(redisScript, Collections.singletonList(key), String.valueOf(quantity)); return result ! null result 0; }这种方案在某压力测试中实现了以下指标场景QPS平均响应时间错误率纯数据库方案1,200450ms0.8%Redis预扣减方案28,00038ms0.01%3. 防超卖三重保险从客户端到数据库超卖问题是高并发系统的噩梦我们采用分层防御策略3.1 前端基础防御禁用重复提交按钮提交后立即禁用直到收到响应倒计时控制对于热门疫苗进入详情页时启动10分钟倒计时本地缓存校验使用localStorage记录用户近期操作3.2 服务端中级防护Transactional public AppointmentResult createAppointment(AppointmentRequest request) { // 1. 用户频控检查 if (rateLimiter.exceedLimit(request.getUserId())) { throw new BusinessException(操作过于频繁); } // 2. 库存预扣减Redis if (!stockService.reduceStock(request.getVaccineId(), request.getTimeSlotId())) { throw new BusinessException(库存不足); } // 3. 数据库唯一约束 try { VaccineAppointment appointment new VaccineAppointment(); // 设置各种属性... appointmentMapper.insert(appointment); // 4. 最终库存扣减 stockMapper.reduceAvailable(request.getVaccineId(), request.getTimeSlotId()); return AppointmentResult.success(appointment); } catch (DuplicateKeyException e) { // 补偿Redis库存 stockService.increaseStock(request.getVaccineId(), request.getTimeSlotId()); throw new BusinessException(请勿重复预约); } }3.3 数据库最终防线在库存扣减时使用乐观锁UPDATE vaccine_stock SET available available - 1, version version 1 WHERE vaccine_id #{vaccineId} AND time_slot_id #{timeSlotId} AND available 1 AND version #{version}这种组合方案在某实际项目中将超卖率从最初的1.2%降到了0.0001%以下。4. 实战中的性能调优技巧当系统真正面临高并发时还需要考虑以下优化点连接池配置以HikariCP为例spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000MySQL参数调整参数推荐值说明innodb_buffer_pool_size总内存的70%缓存池大小innodb_flush_log_at_trx_commit2平衡安全与性能sync_binlog100组提交优化max_connections500根据实际调整JVM调优建议# 启动参数示例 java -jar \ -Xms2g -Xmx2g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:ParallelGCThreads4 \ -XX:ConcGCThreads2 \ your-application.jar在压力测试时我们使用JMeter模拟了以下场景5000用户30秒内逐步启动持续运行10分钟随机间隔(1-5秒)发起请求测试结果令人满意平均响应时间89ms错误率0.005%服务器资源占用CPU 65%内存 70%