当前位置：首页 > news >正文

苍穹外卖核心功能模块深度解析：从表结构到业务逻辑

news 2026/3/27 4:32:40

1. 苍穹外卖核心模块架构解析

第一次接触苍穹外卖这个项目时，最让我头疼的就是各种表之间的复杂关系。作为一个典型的O2O餐饮系统，它的核心模块设计其实非常值得深入探讨。记得当时为了理清套餐和菜品的关系，我整整画了三遍ER图才彻底搞明白。

整个系统的骨架建立在五张核心表上：category（分类表）、dish（菜品表）、dish_flavor（菜品口味表）、setmeal（套餐表）和setmeal_dish（套餐菜品关联表）。这就像开餐厅要先准备好厨房设备一样，理解这些表的关联关系是后续开发的基础。其中setmeal_dish这张中间表特别关键，它就像餐厅里的点菜单，把套餐和具体菜品关联起来。

在实际业务中，这些表通过外键形成网状结构。比如一个分类下可以有多个菜品（1:n），一个套餐可以包含多个菜品（m:n）。这种设计带来的灵活性是：同一份水煮鱼既能单点，也能出现在"川菜套餐"里。但随之而来的挑战是，任何涉及多表的操作都需要特别注意数据一致性。

2. 套餐管理模块实现细节

2.1 套餐新增的原子性操作

新增套餐功能看似简单，实则暗藏玄机。我曾在测试环境遇到过这样的情况：套餐基础信息保存成功了，但关联菜品却没加上，导致用户下单后商家端看到的竟然是空套餐！这就是典型的事务控制问题。

正确的做法应该像这样：

@Transactional public void addSetmealWithDishes(SetmealDTO setmealDTO) { // 1. 保存套餐基本信息 Setmeal setmeal = new Setmeal(); BeanUtils.copyProperties(setmealDTO, setmeal); setmealMapper.insert(setmeal); // 2. 保存套餐菜品关系 List<SetmealDish> setmealDishes = setmealDTO.getSetmealDishes(); setmealDishes.forEach(dish -> { dish.setSetmealId(setmeal.getId()); setmealDishMapper.insert(dish); }); }

这里有几个关键点：

@Transactional注解确保了两个插入操作要么全部成功，要么全部回滚
要先获取套餐主键ID，再设置关联菜品的外键值
使用DTO对象接收前端数据，避免频繁操作数据库

2.2 起售停售的级联检查

起售/停售功能最容易被忽视的就是状态一致性。有次我在生产环境就踩过坑：起售了一个包含停售菜品的套餐，导致用户能下单却无法制作。后来我们增加了这样的校验逻辑：

public void startOrStopSetmeal(Long id, Integer status) { // 检查套餐内菜品状态 List<Dish> dishList = dishMapper.getBySetmealId(id); if (status == 1) { // 起售操作 dishList.forEach(dish -> { if (dish.getStatus() == 0) { throw new CustomException("包含停售菜品"+dish.getName()); } }); } // 更新套餐状态 Setmeal setmeal = Setmeal.builder() .id(id) .status(status) .build(); setmealMapper.update(setmeal); }

这个业务逻辑的精妙之处在于：

起售时检查所有关联菜品状态
停售时无需检查直接操作
使用构建器模式创建更新对象
自定义异常提供明确错误信息

3. 复杂查询的优化实践

3.1 套餐分页查询的联表技巧

套餐列表页需要展示分类名称，这就涉及到setmeal和category表的联查。早期版本我们使用了N+1查询的方式，结果性能惨不忍睹。优化后的Mapper应该是这样的：

<select id="pageQuery" resultType="com.sky.vo.SetmealVO"> SELECT s.*, c.name as categoryName FROM setmeal s LEFT JOIN category c ON s.category_id = c.id <where> <if test="name != null"> AND s.name like concat('%',#{name},'%') </if> <if test="categoryId != null"> AND s.category_id = #{categoryId} </if> <if test="status != null"> AND s.status = #{status} </if> </where> ORDER BY s.create_time DESC </select>

几个优化点值得注意：

使用LEFT JOIN避免分类为空的套餐丢失
动态WHERE条件减少数据库压力
直接返回VO对象避免多次转换
创建时间倒序排列符合业务场景

3.2 删除操作的前置校验

删除套餐是个危险操作，我们至少要检查两点：

套餐是否正在销售中（status=1）
是否有历史订单关联

对应的Service层代码应该这样写：

public void deleteWithDishes(List<Long> ids) { // 检查售卖状态 Integer count = setmealMapper.countByIdsAndStatus(ids, 1); if (count > 0) { throw new CustomException("套餐售卖中不可删除"); } // 删除套餐菜品关系 setmealDishMapper.deleteBySetmealIds(ids); // 删除套餐 setmealMapper.deleteByIds(ids); }

这里有个设计细节：先删关联表再删主表。就像拆房子要先搬走家具一样，这个顺序不能错。同时批量操作使用ids而不是循环单条删除，能显著提高性能。

4. 数据一致性的保障机制

4.1 套餐修改的同步策略

修改套餐信息时，最复杂的就是处理菜品变化。我们采用的"先删后加"策略虽然看起来粗暴，但实际非常有效：

@Transactional public void updateWithDishes(SetmealDTO setmealDTO) { // 更新套餐基础信息 Setmeal setmeal = new Setmeal(); BeanUtils.copyProperties(setmealDTO, setmeal); setmealMapper.update(setmeal); // 删除原有菜品关系 setmealDishMapper.deleteBySetmealId(setmeal.getId()); // 重新添加现有菜品 List<SetmealDish> dishes = setmealDTO.getSetmealDishes(); if (!dishes.isEmpty()) { dishes.forEach(dish -> dish.setSetmealId(setmeal.getId())); setmealDishMapper.insertBatch(dishes); } }

这种方案的优势在于：

完全以最新数据为准，避免部分更新导致的不一致
批量操作减少数据库交互次数
事务保证整个操作的原子性

4.2 状态同步的最终一致性

当菜品停售时，所有包含该菜品的套餐也应该自动停售。我们通过事件驱动的方式实现这个需求：

// 菜品停售事件处理 @Transactional public void stopDish(Long id) { // 停售菜品 Dish dish = Dish.builder() .id(id) .status(0) .build(); dishMapper.update(dish); // 查找包含该菜品的套餐 List<Long> setmealIds = setmealDishMapper.getSetmealIdsByDishId(id); if (!setmealIds.isEmpty()) { // 批量停售套餐 setmealMapper.updateStatusByIds(setmealIds, 0); } }

这个实现考虑了：