毕业设计校园在线点餐系统：从单体架构到高并发服务的技术演进与避坑指南

毕业设计校园在线点餐系统：从单体架构到高并发服务的技术演进与避坑指南

摘要：许多同学在毕设里做“校园在线点餐”，功能画得很全，一到答辩演示就翻车：并发一高订单重复、库存超卖、接口 504。本文用教学项目里踩过的坑，带你从 Spring Boot 单体一路拆到微服务，给出可直接复制的 Redis+Lua 库存脚本、Token 幂等代码、JMeter 压测报告和线上配置样例，让你两周内交出“能扛 500 并发”的答卷。

1. 背景：为什么点餐系统总翻车

校园网高峰期只有 11:30-12:30 一小时，却要把全天 70% 订单写完。去年指导的 42 份毕设里，出现频率最高的三声“哀嚎”如下：

1. “老师，我明明只点了一次，却生成了 3 条订单！”——接口没做幂等。
2. “库存设成 50，结果卖出 63 份黄焖鸡”——并发扣减非原子。
3. “并发 50 的时候接口 7 秒才返回”——全表锁+无索引。

痛点一句话：功能列表人人会画，并发控制才是分水岭。

2. 技术选型：单体 or 微服务？先想清楚“毕设三角”

本科毕设有三角约束：时间少、人手少、评审老师看不懂。把两种架构放在同一张表，能直观看出边界。

结论：毕设场景下，“可运行的单体”+“关键节点可扩展”是最优解；把订单、支付、菜单拆成三个服务，属于“炫技减分”。

3. 核心实现：库存与幂等

3.1 Redis + Lua 原子扣减

数据库行锁在并发 200 时就把 MySQL CPU 打满，改用 Redis 存储剩余库存，利用 Lua 脚本保证“查询-扣减”原子性。

-- decrement_stock.lua local key = KEYS[1] local num = tonumber(ARGV[1]) local stock = tonumber(redis.call('get', key) or 0) if stock < num then return -1 -- 库存不足 end return redis.call('decrby', key, num)

Java 侧调用：

Long left = redis.execute( RedisScript.of(new ClassPathResource("lua/decrement_stock.lua"), Long.class), Collections.singletonList("stock:" + skuId), String.valueOf(quantity) ); if (left < 0) throw new StockException("库存不足");

3.2 Token 机制防重复提交

下单流程拆两步：

1. 进入结算页，前端先调/order/token申请 UUID，服务端放 Redis 并设置 5 min 过期。
2. 真正提交时把 token 带在 Header，后端用 Lua 脚本“判断存在即删除”，保证同一 token 只能用一次。

-- token_consume.lua if redis.call('exists', KEYS[1]) == 1 then return redis.call('del', KEYS[1]) else return 0 end

4. 代码示例：OrderService 下单方法（含注释）

@Service public class OrderService { @Autowired private StringRedisTemplate redis; @Autowired private OrderMapper orderMapper; // 下单接口，已整合库存扣减 + 幂等校验 @Transactional(rollbackFor = Exception.class) public Long createOrder(CreateOrderDTO dto) { // 1. 幂等校验 String tokenKey = "token:" + dto.getToken(); Long result = redis.execute( RedisScript.of(new ClassPathResource("lua/token_consume.lua"), Long.class), Collections.singletonList(tokenKey)); if (result == 0L) throw new ApiException("订单重复提交"); // 2. 扣库存 String stockKey = "stock:" + dto.getSkuId(); Long left = redis.execute( RedisScript.of(new ClassPathResource("lua/decrement_stock.lua"), Long.class), Collections.singletonList(stockKey), String.valueOf(dto.getQuantity())); if (left < 0) throw new StockException("库存不足"); // 3. 写订单 Order order = new Order(); order.setUserId(dto.getUserId()); order.setSkuId(dto.getSkuId()); order.setQuantity(dto.getQuantity()); order.setStatus(1); // 待支付 orderMapper.insert(order); return order.getId(); } }

5. 性能与安全：JMeter 压测 + 基础防护

5.1 压测脚本

• 线程数：500
• ramp-up：10 s
• 循环：每人 2 次
• 结果（本地笔记本，i7-12700 + 16G）：

结论：Redis 挡一层后，同样代码 TPS 提升 11 倍，错误率归零。

5.2 安全三板斧

1. SQL 注入：MyBatis 一律用#{}，禁止${}拼接。
2. XSS：Spring Boot 2.7+ 内置Jackson2ObjectMapperBuilder，把StringHttpMessageConverter默认加上HtmlUtils.htmlEscape。
3. 日志脱敏：统一 Logback 过滤器，把 11 位手机中间 4 位换成星号，避免 GitHub 传日志泄露隐私。

6. 生产环境避坑清单

1. MySQL 行锁升级：库存扣减改走 Redis 后，订单表只负责持久化，不再用select ... for update，避免间隙锁扩大。
2. Nginx 静态资源缓存：食堂图片 1-2 M 很常见，加一行location ~* \.(jpg|png)$ { expires 1d; add_header Cache-Control "public"; }，减少 60% 带宽。
3. 日志脱敏：用 Logback 的TurboFilter对手机号、邮箱正则匹配，* 号替换后再落盘，防止助教拷走日志后泄露数据。
4. 容器内存：Docker 默认不设 JVM 堆，启动脚本加-XX:MaxRAMPercentage=75.0，避免 4 G 的云主机频繁 OOMMKilled。
5. 监控留白：毕设不需要上 Prometheus 集群，但本地可跑spring-boot-actuator+micrometer-registry-prometheus，答辩时打开 Grafana 瞬时值，老师一看“有图有真相”。

7. 思考与动手

毕设周期只有 10-12 周，功能完整性和系统健壮性永远在做权衡。先让单体“能跑”，再把并发最高的两个点（库存、幂等）用 Redis 解决，就能在有限时间里交出“能演示、能压测、能答辩”的三能系统。读完不妨 fork 示例仓库，把 Lua 脚本和 JMeter 文件拉到本地，亲手跑一次 500 线程，看控制台 TPS 冲到 2000+ 时，你会对“高并发”三个字有体感级的理解。

下一步，试试把支付回调、消息队列、分布式事务留作研究生阶段的续篇——毕竟，毕设只是起点，坑还很长。祝你编码顺利，答辩一次过！