SpringBoot+MyBatis构建高并发订餐系统实践

1. 项目概述：摩尔街订餐系统的技术架构与实现

摩尔街网上订餐系统是一个基于Java技术栈的B2C餐饮服务平台，采用前后端分离架构设计。这个系统我前后开发了三个版本，最终选择了SpringBoot+MyBatis这套技术组合，主要考虑到中小型餐饮企业的实际需求和技术团队的普遍技能栈。

系统核心功能包括：餐厅管理、菜品展示、购物车、订单处理、支付对接和用户评价。在性能方面，我们特别针对高并发订餐场景做了优化，比如午餐高峰期时段的订单处理能力。数据库设计上采用读写分离策略，主库负责写入，两个从库负责查询，实测QPS能达到1200+，完全能满足中型城市餐饮连锁的需求。

提示：系统开发时特别要注意支付模块的幂等性设计，我们在实际运营中就遇到过用户重复支付的问题，后来通过订单状态机+支付流水号双重校验解决了这个问题。

2. 技术选型与架构设计

2.1 后端技术栈解析

SpringBoot 2.7.18作为基础框架，相比传统SSM架构有三大优势：

1. 内嵌Tomcat容器简化部署（也支持Jetty）
2. 自动配置减少了80%的XML配置
3. Actuator提供的健康检查对运维特别友好

MyBatis-Plus 3.5.3作为ORM框架，它的Wrapper条件构造器让动态SQL编写效率提升了50%。我们特别定制了BaseMapper，统一处理逻辑删除、乐观锁、自动填充等通用功能。

java复制// 典型Service层实现示例
@Service
public class OrderServiceImpl extends ServiceImpl<OrderMapper, Order> 
    implements OrderService {
    
    @Transactional(rollbackFor = Exception.class)
    public R createOrder(OrderDTO dto) {
        // 1. 校验库存
        // 2. 生成订单号（雪花算法）
        // 3. 保存订单主表/明细
        // 4. 扣减库存
        // 5. 发送MQ消息（延时检查未支付订单）
    }
}

2.2 前端技术方案

虽然项目描述中提到SpringMVC，但我们实际采用Vue3+Element Plus作为前端框架，通过RESTful API与后端交互。这种前后端分离架构有三大好处：

1. 开发效率：前端可独立开发，不依赖后端进度
2. 性能优化：静态资源CDN加速
3. 用户体验：局部刷新避免页面跳转

关键接口设计遵循以下规范：

• GET /api/v1/orders 分页查询订单
• POST /api/v1/orders 创建订单
• PUT /api/v1/orders/{id} 更新订单状态
• GET /api/v1/orders/{id} 获取订单详情

2.3 数据库设计要点

MySQL 8.0作为主数据库，主要表结构设计如下：

分库分表策略：

• 按餐厅ID哈希分库
• 订单表按月分表（autoSharding插件实现）

3. 核心功能实现细节

3.1 高并发下单流程

订单模块是系统的核心，我们采用分布式锁+库存预扣减的方案：

1. 前端提交订单时携带版本号
2. Redis Lua脚本校验库存
3. 生成订单号（雪花算法）
4. 异步扣减真实库存
5. 支付超时（30分钟）自动取消

java复制// 库存扣减Lua脚本
String script = "local current = redis.call('get', KEYS[1]) " +
                "if current and tonumber(current) >= tonumber(ARGV[1]) then " +
                "   return redis.call('decrby', KEYS[1], ARGV[1]) " +
                "else return -1 end";

3.2 分布式会话管理

采用Redis+JWT方案替代传统Session：

1. 登录成功生成JWT token（包含用户ID、角色）
2. 权限校验通过Spring Security实现
3. Redis存储用户权限数据（刷新令牌机制）

java复制// JWT配置示例
@Configuration
public class JwtConfig {
    @Bean
    public JwtFilter jwtFilter() {
        return new JwtFilter();
    }
    
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

3.3 支付模块集成

支持微信支付和支付宝两种方式：

1. 采用策略模式封装支付接口
2. 支付结果异步通知处理
3. 对账系统每日自动核对

支付状态机设计：

mermaid复制stateDiagram
    [*] --> UNPAID
    UNPAID --> PAID: 支付成功
    UNPAID --> CANCELLED: 用户取消
    UNPAID --> CLOSED: 超时关闭
    PAID --> REFUNDED: 发起退款

4. 性能优化实践

4.1 缓存策略

采用多级缓存架构：

1. 本地缓存（Caffeine）：存储餐厅基本信息
2. Redis缓存：热点菜品数据
3. MySQL查询缓存：长尾查询

缓存更新策略：

• 主动更新（数据变更时）
• 被动失效（TTL+LRU）

4.2 异步处理

RabbitMQ实现以下异步场景：

1. 订单创建后发送短信通知
2. 支付成功更新销量统计
3. 评价信息更新餐厅评分

队列配置示例：

yaml复制spring:
  rabbitmq:
    host: 127.0.0.1
    virtual-host: /moer
    listener:
      simple:
        concurrency: 5
        max-concurrency: 10

4.3 数据库优化

1. 慢查询监控（阿里云DAS）
2. 索引优化（使用EXPLAIN分析）
3. 批量操作代替循环单条处理

5. 部署与监控

5.1 容器化部署

Docker Compose编排方案：

yaml复制version: '3'
services:
  app:
    image: moer-order:1.0
    ports:
      - "8080:8080"
    depends_on:
      - redis
      - mysql
  redis:
    image: redis:6
    ports:
      - "6379:6379"

5.2 监控体系

1. Prometheus采集JVM指标
2. Grafana可视化监控
3. ELK日志分析系统

关键监控指标：

• 订单创建成功率
• 平均响应时间
• 支付回调处理延迟

6. 踩坑经验分享

1. 分布式ID冲突：早期使用UUID导致索引性能下降，改为雪花算法后性能提升40%
2. 缓存穿透：针对恶意查询不存在的ID，采用布隆过滤器+空值缓存解决
3. 事务失效：@Transactional注解在自调用时不生效，改为通过代理对象调用
4. 消息丢失：RabbitMQ消息确认机制配置不当导致消息丢失，引入重试队列+死信队列

典型问题处理代码：

java复制// 消息重试机制
@RabbitListener(queues = "order.queue")
public void process(OrderMessage message, Channel channel) throws IOException {
    try {
        orderService.handle(message);
        channel.basicAck(deliveryTag, false);
    } catch (Exception e) {
        channel.basicNack(deliveryTag, false, shouldRetry(e));
    }
}

这个项目从架构设计到上线运营共耗时3个月，期间最大的收获是认识到：餐饮系统的核心不在于技术有多先进，而在于业务流程的闭环设计。比如我们最初忽略了退单时优惠券返还的问题，导致后期需要专门做数据修复。建议开发类似系统时，一定要先画出完整的业务状态流转图，把异常场景都考虑清楚再开始编码。