从零到一理解苍穹外卖Day04：套餐状态与菜品状态的联动校验到底怎么做？

苍穹外卖Day04：套餐与菜品状态联动的深度校验实践

在餐饮管理系统的开发中，套餐与菜品状态的联动校验是一个看似简单却暗藏玄机的业务场景。想象一下这样的场景：当用户试图将一个套餐设置为"起售"状态时，系统必须确保该套餐包含的所有菜品都处于可售状态。这种业务规则不仅关乎数据一致性，更直接影响用户体验和系统可靠性。

1. 状态联动校验的核心逻辑剖析

1.1 业务场景的复杂性

套餐与菜品的关系本质上是一种组合模式。一个套餐通常包含多个菜品，这种一对多的关系在数据库中表现为：

-- 套餐表 CREATE TABLE setmeal ( id BIGINT PRIMARY KEY, name VARCHAR(32), status TINYINT COMMENT '1-起售 0-停售' ); -- 套餐菜品关联表 CREATE TABLE setmeal_dish ( setmeal_id BIGINT, dish_id BIGINT, PRIMARY KEY (setmeal_id, dish_id) ); -- 菜品表 CREATE TABLE dish ( id BIGINT PRIMARY KEY, name VARCHAR(32), status TINYINT COMMENT '1-起售 0-停售' );

当执行套餐起售操作时，系统需要：

1. 查询该套餐关联的所有菜品
2. 检查每个菜品是否为起售状态(1)
3. 如果存在停售菜品(0)，则阻止套餐起售

1.2 多表关联查询的实现

在苍穹外卖的实现中，关键SQL查询如下：

@Select("select d.* from dish d left join setmeal_dish sd on d.id=sd.dish_id where sd.setmeal_id=#{id}") List<Dish> getDish(Long id);

这个查询通过左连接将菜品表与套餐菜品关联表结合，返回指定套餐下的所有菜品数据。值得注意的是：

• 使用左连接确保即使关联关系异常也能返回部分结果
• 查询结果直接映射到Dish实体，便于后续业务处理
• 条件过滤仅基于套餐ID，查询效率较高

1.3 状态校验的业务逻辑

校验逻辑的核心代码片段：

if(status == StatusConstant.ENABLE) { List<Dish> dishes = dishMapper.getDish(id); if(dishes != null && dishes.size() > 0) { for (Dish dish : dishes) { if(dish.getStatus() == StatusConstant.DISABLE) { throw new SetmealEnableFailedException(MessageConstant.SETMEAL_ENABLE_FAILED); } } } }

这段代码体现了几个重要设计原则：

1. 防御性编程：先检查dishes是否为null及非空
2. 快速失败：发现第一个停售菜品立即抛出异常
3. 明确异常：使用自定义异常区分业务校验失败与其他异常

2. 性能优化与替代方案

2.1 现有方案的性能瓶颈

当前实现存在几个潜在性能问题：

1. N+1查询问题：批量操作时可能产生大量单条查询
2. 全量数据加载：即使只需要检查状态字段也加载了全部菜品信息
3. 缺乏缓存：重复校验相同菜品时反复查询数据库

2.2 优化方案对比

状态字段冗余示例：

ALTER TABLE setmeal ADD COLUMN has_disabled_dish TINYINT DEFAULT 0 COMMENT '是否包含停售菜品';

通过维护这个冗余字段，可以在套餐起售时快速判断，无需关联查询。

2.3 缓存策略的实现

引入Redis缓存菜品状态的示例代码：

// 检查菜品状态时先查缓存 public boolean isDishEnabled(Long dishId) { String key = "dish:status:" + dishId; String status = redisTemplate.opsForValue().get(key); if(status != null) { return "1".equals(status); } Dish dish = dishMapper.selectById(dishId); if(dish == null) { return false; } redisTemplate.opsForValue().set(key, dish.getStatus().toString(), 1, TimeUnit.HOURS); return dish.getStatus() == StatusConstant.ENABLE; }

提示：使用缓存时需要考虑缓存一致性问题，当菜品状态变更时需要及时更新缓存

3. 异常处理与事务管理

3.1 自定义业务异常设计

苍穹外卖中定义了专门的业务异常：

public class SetmealEnableFailedException extends BaseException { public SetmealEnableFailedException(String msg) { super(msg); } }

这种设计的好处包括：

• 与系统异常区分，便于前端特殊处理
• 可携带更丰富的业务上下文信息
• 便于集中式异常处理和日志记录

3.2 事务边界控制

状态变更操作通常需要事务保证：

@Override @Transactional public void status(Integer status, Long id) { // 校验逻辑 if(status == StatusConstant.ENABLE) { // ... 校验代码 } // 更新操作 Setmeal setmeal = new Setmeal(); setmeal.setStatus(status); setmeal.setId(id); setmealMapper.update(setmeal); }

注意事务的几点最佳实践：

1. 事务方法尽量保持简短
2. 避免在事务中进行远程调用
3. 合理设置事务隔离级别和传播行为

4. 前端交互与用户体验

4.1 提前校验的优化策略

与其等到用户尝试起售时才报错，更好的做法是：

1. 在套餐编辑页面显示包含的停售菜品数量
2. 对包含停售菜品的套餐禁用起售按钮
3. 鼠标悬停时显示具体哪些菜品处于停售状态

4.2 批量操作的优化处理

当处理批量起售操作时，可以：

1. 先快速检查所有套餐的可起售性
2. 对无法起售的套餐给出明确原因
3. 提供"仅起售可操作的套餐"选项

示例响应结构：

{ "success": [1001, 1002], "failed": [ { "id": 1003, "reason": "包含停售菜品：鱼香肉丝" } ] }

5. 测试用例设计要点

5.1 关键测试场景

针对状态联动校验，至少需要覆盖：

1. 套餐无关联菜品时的起售操作
2. 套餐所有菜品已起售时的起售操作
3. 套餐包含一个停售菜品时的起售操作
4. 套餐全部菜品停售时的起售操作
5. 停售操作不受菜品状态影响的情况

5.2 性能测试指标

需要特别关注的性能指标：

1. 单套餐校验的平均响应时间
2. 批量操作时的吞吐量
3. 高并发下的错误率
4. 数据库查询次数和负载

6. 扩展思考：状态管理的设计模式

在更复杂的系统中，可以考虑使用状态模式来管理这种联动关系：

public interface SetmealState { void enable(); void disable(); } public class DraftState implements SetmealState { private SetmealContext context; @Override public void enable() { if(!context.areAllDishesEnabled()) { throw new IllegalStateException("包含停售菜品"); } context.setState(new EnabledState()); } // ... 其他方法 }

这种设计虽然增加了复杂度，但带来了更好的扩展性，特别是当业务规则变得更加复杂时。