餐饮系统毕业设计中的效率瓶颈与优化实践：从单体架构到模块解耦-深圳市維司達科技有限公司

餐饮系统毕业设计中的效率瓶颈与优化实践：从单体架构到模块解耦

适合读者：计算机专业本科生、刚接触高并发场景的应届开发者

关键词：餐饮系统、毕业设计、效率优化、消息队列、缓存、幂等性

一、为什么“点餐”总卡？——典型痛点拆解

去年指导学弟做餐饮系统毕设，演示当天 30 个同学同时扫码下单，页面直接转圈 8 秒，库存还超卖了 3 份麻辣小龙虾。事后复盘，问题集中在下面 3 点：

订单与库存同库同表，下单接口里SELECT → 业务计算 → UPDATE三步走事务，行锁排队，并发一上来就互相拖死。
前端没做防抖，用户狂点“提交”，后端重复落库，造成订单号重复、支付回调异常。
页面轮询订单状态，1 秒一次，高峰期 200 个长连接把 Tomcat 默认 200 线程占满，后续请求直接 502。

一句话：单体架构 + 同步调用 + 无幂等 = 高并发必翻车。

二、技术选型对比——别让数据库扛下所有

| 场景 | 传统做法 | 瓶颈 | 优化方案 | 理由 | |---|---|---|---|---|---|---| | 库存扣减 | MySQL 行级锁 | 并发 50 TPS 就开始锁等 | Redis + Lua 脚本 | 单线程 + 原子指令，轻松 2000 TPS | | 订单创建 | 同步调用支付、库存、优惠券 | 任一接口超时，整体重试 | RabbitMQ 异步消息 | 下游故障上游无感，可削峰填谷 | | 热数据读取 | 每次都查 DB | QPS 高时 DB CPU 飙红 | 本地 Caffeine + Redis 二级缓存 | 命中率达 90%，RT 从 120 ms 降到 8 ms |

结论：“缓存 + 消息队列”不是大公司的专利，毕业设计同样玩得转。

三、核心实现细节

下面给出经过教学项目验证的 4 个关键代码片段，全部基于 Spring Boot 2.7 + MyBatis-Plus + RabbitMQ + Redis 6.2。

3.1 订单幂等令牌——前端“提交”按钮只让点一次

// OrderController.java @PostMapping("/order") public IdResp create(@RequestBody OrderDTO dto, HttpServletRequest req){ // 1. 从网关统一头里拿 userId Long userId = UserContext.get(); // 2. 组装业务幂等 Key String idemKey = "order:uid:"+userId+":sku:"+dto.getSkuId(); // 3. Redis SET NX EX 原子性放令牌，10 s 过期 Boolean ok = stringRedisTemplate.opsForValue() .setIfAbsent(idemKey,"1",Duration.ofSeconds(10)); if (Boolean.FALSE.equals(ok)){ throw new BizException("订单提交中，请勿重复点击"); } // 4. 发送创建指令到队列，立即返回 rabbitTemplate.convertAndSend("order.event", dto); return IdResp.accepted(); // 只返回 202，不阻塞 }

说明：利用 Redis 单线程 + 过期时间窗，解决“双击”导致的重复下单，10 s 足够后端消息消费完。

3.2 Redis+Lua 原子扣库存——把“超卖”扼杀在内存里

-- stockDeduct.lua local key = KEYS[1] -- 库存 Key local num = tonumber(ARGV[1])-- 购买量 local left = redis.call('GET', key) if not left then return -1 end if tonumber(left) < num then return 0 end return redis.call('DECRBY', key, num)

// StockService.java public boolean deduct(String skuId, int num){ Long left = (Long) redisTemplate.execute( stockDeductScript, Collections.singletonList("stock:"+skuId), String.valueOf(num) ); return left!=null && left>=0; }

把脚本提前SCRIPT LOAD缓存到 Redis，调用时直接走 EVALSHA，RT 控制在 2 ms 内。

3.3 缓存与 DB 双写一致性——先删缓存再更新 DB，延迟消息兜底

下单成功后，先删除缓存中的库存；
异步消费队列里再异步刷新缓存，防止并发读写脏数据；
若缓存失效期间又有读请求，短暂穿透到 DB，利用互斥锁保证只回源一次。

伪代码：

@RabbitListener(queues = "stock.refresh") public void refreshStock(StockRefreshEvent evt){ Stock s = stockMapper.selectById(evt.getSkuId()); redisTemplate.opsForValue().set("stock:"+evt.getSkuId(), s.getLeft()); }

3.4 事务边界划分——本地事务只关心订单，库存走最终一致

@Transactional(rollbackFor = Exception.class) public void insertOrder(Order order){ orderMapper.insert(order); // 不远程调库存，只发消息 rabbitTemplate.convertAndSend("stock.deduct", new StockDeductDTO(order)); }

事务范围小，锁时间短；库存服务消费消息时失败可重试，保证最终一致。

四、完整可运行示例（精简版）

项目结构：

com.example.food ├── controller ├── service │ └── impl │ └── OrderServiceImpl.java ├── mq │ └── StockDeductConsumer.java └── config └── RedisLuaConfig.java

关键类已在前文给出，仓库地址（教学用，已脱敏）：
https://github.com/yourrepo/food-order-benchmark
clone 后docker-compose up -d即可拉起 MySQL、Redis、RabbitMQ，一键运行FoodOrderApplication。

五、性能测试 & 安全考量

测试环境：
Mac M1 16 G，Docker 限制 4 Core / 4 G；JMeter 200 线程循环压测 60 s。

指标	优化前（单体）	优化后（缓存+MQ）
平均 RT	1100 ms	95 ms
峰值 QPS	42	510
CPU 占用	MySQL 90 %	Redis 35 %

安全点补充：

防刷单：接口网关层限流 + 用户维度令牌桶（Bucket4j）
SQL 注入：MyBatis-Plus 内置预编译，额外开启全局过滤器sqlInjectionFilter
消息幂等：消费端用“订单号 + 状态机”做唯一索引，重复消息直接 ACK

六、生产环境避坑指南

冷启动延迟：Spring Boot 3.x 原生编译后首次 RabbitMQ 连接可能 5 s+，提前spring-rabbit的ConnectionFactory预热。
日志追踪缺失：引入 Sleuth + Zipkin，消息头里强制带上traceId，否则 MQ 一拆调用链就断。
事务边界过大：不要在@Transactional里发 HTTP 调用，极易因为超时导致 DB 连接池被打满。
Redis 大 Key：库存每天定时归档，历史数据落到 MySQL，热 Key 长度保持在 1 KB 以内。
缓存雪崩：给 Redis 设置随机 TTL（±300 s），防止同一时刻集体失效回源。