Spring Boot餐饮购票选座系统：推荐算法与并发控制实践

拿到“Spring Boot基于移动端推荐算法的线上餐饮购票选座系统”这个题目时，我第一反应是：这个毕设选题把餐饮行业数字化的几个硬骨头一次凑齐了。搜店靠推荐、抢座靠手速、核销靠人工，这三件事在传统餐饮门店里是割裂的，而这套系统要用一套闭环把它们串起来。跑通之后的效果大概是这样的：用户在小程序里刷到个性化推荐的餐厅，点进去选择一个用餐场次，购买餐位号票，然后在座位图上挑一个靠窗或者安静的位置，提交订单并支付；商家端则负责维护座位布局、设置场次容量、在核销台完成到店确认。

这套流程单独看每一块都是毕设里高分素材：推荐算法体现数据分析能力，选座并发控制体现工程能力，移动端体现产品完整度，后端接口设计体现基本功。这篇内容适合两类人参考，一类是正在纠结毕设题目的同学，想评估工作量和技术路线；另一类是毕业后想进餐饮SaaS行业、或者对“推荐+交易”类系统感兴趣的开发者。文章不打算只罗列功能点，会尽量把模块之间如何咬合、状态如何流转、并发问题如何解决这一点点讲清楚，尽量避免那些“拆包即用”的思路。

1. 项目全貌：线上餐饮购票选座在解决什么现实问题

1.1 线下餐饮的三个真实痛点

去热门餐厅吃饭，最常见的体验是：到店取号，服务员说前面还有二十桌，预计等一小时；想坐靠窗的位置，得现场跟服务员商量，人家只能告诉你“有客人预定了”；推荐菜完全靠服务员口头推销，不同顾客拿到的信息一模一样，没有任何个性化。

站在商家角度来看，问题更明显。座位闲置时段没有工具做促销，热门餐位被黄牛占号没有追溯手段，当天入座率只能靠店长下班后手工统计。顾客离店之后，商家不知道他喜欢吃什么、会不会再来，复购全靠缘分。

这套线上餐饮购票选座系统，本质上是把“餐厅容量”变成了一种可在线售卖的库存资源。座位不再是一张静态的桌子，而是分场次、分状态、可锁定的资源单位。购买餐位票、选择场次、锁定座位、支付、到店核销，整个链路和影院售票系统高度相似，但细节上又比影院多出餐饮特有的逻辑，比如菜品推荐、用餐时长限制、餐位与菜品的绑定关系。

1.2 系统的业务闭环与角色划分

系统的角色可以拆成三类：用户、商家、平台运营。用户端的核心路径是“逛-选-买-坐”，具体拆开是首页推荐流、餐厅详情、场次购票、座位选择、订单支付、到店核销。商家端的核心路径是“排-管-核”，也就是排场次、管座位、核销订单。平台运营则关注数据统计和内容配置。

这里要注意一个容易被忽略的地方：购票不是买菜品，而是买“某个时间段内餐厅的入场资格与座位使用权”。所以系统里有“场次”这个概念。比如某家餐厅午餐场11:00到13:00，晚餐场17:00到21:00，每个场次对应一批可售座位数。用户在某个场次购票后，座位状态就变成“已售”。这就把餐饮的翻台率和电影院的场次巧妙地结合了，也避免了无限制排队取号的混乱。

1.3 为什么这套系统适合用Spring Boot实现

Spring Boot在这个项目里几乎是不二之选。理由很实在：第一，毕设周期通常三到五个月，Spring Boot的自动配置和生态能把开发速度拉满；第二，MyBatis-Plus让单表CRUD不用手写XML，能把精力留给核心业务；第三，Spring的声明式事务和AOP很适合订单、库存这类强一致性场景。换个冷门框架，光是环境问题就能耗掉两周。

更关键的是，Java生态在校园里普及度高，答辩时老师提问的主流问题都能在Spring Boot体系内找到明确答案，比如依赖注入、事务传播、拦截器、Redis缓存等。项目源码19432这个编号也说明了它是典型的计算机毕业设计交付物，意味着需要同时具备可演示的前端页面、完整的后端接口、以及能跑通的数据库脚本。

2. 技术选型与整体架构拆解

2.1 技术栈全景

我做的这个版本，技术栈是经过几轮权衡后定下来的，列成表格供参考：

2.2 移动端选型的思考：为什么不选纯原生

题目里明确写了“基于移动端”，所以移动端页面是必须有的。但选原生Android还是跨平台方案，值得仔细斟酌。原生开发在毕业设计里确实更“显功夫”，但工作量很容易失控，光是一个自定义座位图控件加手势缩放，就可能耗掉两到三周。

我的选择是UniApp，配合Vue 3语法。理由有三条：一是它编译成微信小程序后演示非常方便，老师手机扫码就能看；二是Vue语法是前端主流，答辩解释起来顺畅；三是UI组件库丰富，像座位图这种复杂交互可以基于 简单网格组件二次开发，不用从零造轮子。

如果你更熟悉Flutter，用Flutter也完全可以，但要注意后端的接口字段设计要预留跨端适配空间。移动端和后端的通信统一走RESTful JSON接口，JWT放在Header里，这样不管以后换小程序还是App，后端都不用动。

2.3 后端分层结构与模块边界

后端我分成五层：Controller层只做参数接收和结果包装；Service层承载业务规则；Mapper层做数据访问；Domain层放实体和领域逻辑；Common层放工具类、异常处理、常量定义。这种分层是Spring Boot项目的标准范式，但很多人写代码时会逐渐退化成“Controller里写SQL”，这是大忌。

具体到模块边界，我建议这样划分：

• 用户模块：注册、登录、个人中心
• 餐厅模块：餐厅列表、详情、评分、菜品
• 场次模块：场次设置、余票数量
• 座位模块：座位图配置、状态管理、锁定与释放
• 订单模块：创建订单、支付回调、核销、退款
• 推荐模块：行为采集、相似度计算、推荐列表生成
• 管理模块：商家端数据、财务报表

模块之间通过Service接口调用，禁止跨模块访问Mapper。这样划分之后，推荐算法的升级不会影响订单模块，座位状态的变化也不会散落在多个Controller里。

2.4 为什么引入Redis：不只是缓存

很多毕设里Redis的角色就是“存个登录态”或者“缓存一下热点数据”，但在这个项目里，Redis承担了更重的责任。

第一是座位状态的预校验。当用户打开选座页面，后端会把场次内所有座位的状态从数据库加载到Redis的Hash结构中，格式是seat:lock:{sessionId}，字段是seatId，值是状态码。这样用户点选座位时，可以先查Redis判断是否被占，只有确认空闲才继续走订单流程，大大减少数据库压力。

第二是并发控制。同一时间可能有多个用户点击同一个座位，单纯靠数据库乐观锁也可以，但把SETNX分布式锁和数据库事务结合起来，用户体验会更顺畅。用户在支付前锁住座位15分钟，超过时间自动释放。

第三是做推荐算法的特征存储。用户最近浏览记录、点击行为可以先写入Redis，后台异步任务定时落库，避免高频行为写入影响数据库性能。

3. 核心功能模块与数据库表设计

3.1 表结构设计思路

数据库是这个项目的地基，表设计直接决定了功能能不能跑通。核心表我建议至少包含以下这些：

3.2 座位状态的四种状态与流转

座位状态是这个项目里最容易翻车的地方。我把它设计成四个状态：空闲、锁定、已售、停用。

空闲表示座位可被选购；锁定表示用户已经发起订单但未支付，系统会保留一段时间；已售表示订单支付完成，座位不可再被其他人选择；停用则是商家手动维护，比如该座位桌椅损坏或临时撤掉。

状态流转看起来简单，真正复杂的是锁定状态下的超时释放。用户选座后15分钟内未支付，系统需要把座位重新置为空闲，订单状态改为已取消。这个操作必须有定时任务兜底，我在项目里用的是Spring的@Scheduled注解，每30秒扫描一次超时锁定的座位。如果想省事，也可以借助Redis的过期回调来触发，但可靠性不如主动扫描。

3.3 订单状态机的演进

订单状态直观地反映了整个交易链路。我在项目里设置了这样几种状态：待支付、已支付、已核销、已取消、已退款。

从待支付到已支付，靠的是支付回调。这里有个坑，支付回调可能重复通知，所以必须在回调处理里做幂等，也就是说，同一个订单号只能成功修改一次状态。我是加了一个状态前置校验：只有当前状态是“待支付”时才允许改成“已支付”，否则直接返回成功。

已支付到已核销，靠的是核销二维码。用户在到店后出示订单详情页的核销码，商家在商家端输入或扫码，后端校验订单和场次是否匹配，然后修改状态。这一步和电影院的验票逻辑一致，但会多校验一点，比如当前时间是否在场次时间内。

3.4 用户行为数据的采集与埋点设计

推荐算法要有数据可算，所以用户行为采集是前置条件。我在前端埋了三种行为类型：浏览、点击、购买。浏览行为在用户进入餐厅详情页或菜品详情页时上报；点击行为在用户点击推荐卡片时上报；购买行为在订单支付成功时自动上报。

后端的接收接口是统一的/api/behavior/report，参数包含userId、itemId、behaviorType、sceneId。因为行为数据频率高，我不建议直接插入MySQL，而是先写入Redis列表，然后用定时任务批量刷入user_behavior表。这样做数据库压力小，推荐模块读取数据时也能拿到聚合好的结果。

4. 推荐算法的落地实现：从协同过滤到业务过滤

4.1 先想清楚推荐什么、给谁推荐、用什么信号

很多同学拿到“推荐算法”几个字就直接想到协同过滤公式，但忽略了最重要的前置问题：推荐的目标是什么。

这个系统里推荐的目标分两类，第一类是首页推荐餐厅，第二类是餐厅详情页推荐菜品。前者解决用户“不知道去哪吃”的问题，后者解决“到店不知道点什么”的问题。两者的行为数据不一样，餐厅推荐的信号来源于用户浏览和收藏餐厅，菜品推荐的信号来源于用户下单菜品和浏览菜品。

为了让推荐算法能在有限的数据量下正常工作，我把推荐目标默认聚焦到“菜品推荐”上。因为菜品数量和用户行为记录的规模远大于餐厅数量，协同过滤的相似度矩阵计算更稳定。餐厅推荐则退化为“基于城市和评分的热门列表”，更实用。

4.2 基于物品的协同过滤算法实现步骤

基于物品的协同过滤（Item-CF）的核心假设是：用户对某个物品有兴趣，是因为他之前喜欢的物品与该物品相似。这个“相似”不是类目上的相似，而是行为上的共现，比如很多用户同时购买过A和B，那A和B就被认为相似。

实现步骤拆开是四步。

第一步构建用户-菜品行为矩阵。从user_behavior表里取所有用户的正反馈行为，比如购买和浏览各计1次和0.5次权重，得到一个稀疏矩阵。

第二步计算菜品之间的相似度。我采用的是余弦相似度。假设两个菜品向量分别是a和b，相似度公式是cos(a,b) = a·b / (|a| * |b|)。在具体实现里，不需要把矩阵完整展开成二维数组，用Map嵌套结构，只记录非零元素。

第三步针对目标用户找到其历史正反馈菜品集合，遍历每个历史菜品的相似菜品，累计每个候选菜品的预测评分。预测公式是：用户u对物品i的偏好度 = 用户u对所有已评物品j的评分 * 物品i和物品j的相似度 的总和。

第四步按预测评分排序，去掉用户已经购买过的菜品，取Top N返回。

下面是一段简化版的Java实现，只描述核心逻辑：

public List<Long> recommendByItemCF(Long userId, int topN) { // 1. 获取用户历史正反馈菜品 id -> rating Map<Long, Double> userHistory = behaviorService.getUserPositiveItems(userId); // 2. 构建候选菜品评分map Map<Long, Double> candidateScore = new HashMap<>(); for (Map.Entry<Long, Double> entry : userHistory.entrySet()) { Long itemId = entry.getKey(); Double userRating = entry.getValue(); // 3. 获取与该历史菜品相似的K个菜品 List<SimilarItem> similarItems = similarityService.findTopK(itemId, 10); for (SimilarItem si : similarItems) { if (userHistory.containsKey(si.getItemId())) { continue; // 过滤掉已经购买过的 } candidateScore.merge( si.getItemId(), userRating * si.getSimilarity(), Double::sum ); } } // 4. 排序取TopN return candidateScore.entrySet().stream() .sorted(Map.Entry.<Long, Double>comparingByValue().reversed()) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); }

这里有一个关键优化点：similarityService.findTopK不能实时遍历全量菜品计算相似度，否则接口响应时间会爆。我采用的方案是离线计算相似度矩阵，存入 Redis 的SortedSet，key是item:sim:{itemId}，value是相似菜品id，score是相似度。这样线上推荐时只需从Redis取Top10，毫秒级返回。

4.3 冷启动问题与热门兜底策略

协同过滤最大的天敌是冷启动：新用户没有任何行为记录，新菜品没有任何共现数据，算法直接失效。我的兜底策略是分层处理。

对于新用户，直接给他推荐全局热门菜品，按销量和好评率排序，同时混入一定比例的餐厅推荐，保证首页不是空白。对于新菜品，则在相似度矩阵里暂时缺失的情况下，给予基于类目标签的推荐，比如用户喜欢川菜，就推荐同标签下的高分菜品。

这种冷启动只看数据量，不依赖算法复杂度，但要注意在推荐结果的JSON里加入strategyType字段，标记是“协同过滤”还是“热门兜底”，方便测试期观察效果。

4.4 推荐结果如何与购票业务流程结合

推荐模块不是独立的，它要为购票转化服务。我在设计推荐接口时，返回的菜品列表会带上一个sessionId参数，用户点击推荐菜品卡片，跳转到餐厅详情页，自动选中最近可购票的场次，并预填该菜品作为快捷菜单项。这样推荐到下单的路径被压缩到两次点击以内。

个人主页在完成一单后，我还会定期用“买了A的人也买了B”生成关联推荐，放在订单完成页的“猜你还想点”区域。这部分不需要额外开发接口，直接复用Item-CF的相似度查询。

5. 选座系统与并发控制实战

5.1 选座的业务场景与影院逻辑的异同

餐饮选座和影院选座最大的区别在于：电影票的座位是精确到座位号的，而餐饮座位往往要结合餐桌的容量。一家餐厅可能既有2人桌，也有4人桌和包间，用户选座不仅要选位置，还要匹配就餐人数。这个约束必须在数据层体现。

我在座位表seat里增加了capacity字段表示可坐人数，前端选座页面会先让用户选择就餐人数，然后过滤出容量满足的座位，并对不能满足的座位做置灰处理。用户选座时不能跨桌选多个座位，一张订单只对应一个用餐桌。

5.2 座位状态的并发控制：分布式锁加事务

并发选座最怕的问题是超卖，两个用户同时选中同一个座位，结果两个订单都创建成功。解决思路分两层。

第一层是Redis分布式锁。用户点击座位时，后端先执行SET lock:seat:{sessionId}:{seatId} userId NX EX 900，这个命令的意思是，如果该座位没有被锁，则写入当前用户ID作为锁的持有者，并设置15分钟过期。如果返回失败，说明座位已被锁定，直接返回“座位已被占用”。

第二层是数据库事务。拿到锁之后，在事务中执行更新seat_status的状态为“锁定”，并创建订单记录。事务提交之后才能释放Redis锁。

这里要特别注意释放锁的时机和方式。如果是支付成功后才手动释放，那在支付期间锁应该持续存在；如果是用户取消或超时未支付，则通过定时任务解锁。释放锁用Lua脚本判断持有者身份，防止误删别人的锁。

// 伪代码：释放锁时校验持有者 String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"; redisTemplate.execute(new DefaultRedisScript<>(luaScript, Long.class), Arrays.asList("lock:seat:" + sessionId + ":" + seatId), String.valueOf(userId));

5.3 座位图的数据结构与前端交互

座位图是移动端最容易出效果的页面。后端提供的接口返回该场次下所有座位信息，包括座位的行列坐标和当前状态。前端渲染时用绝对定位，把坐标直接映射成百分比或px值。

这里有一个设计经验：不要在后端把座位状态直接算好返回，而是把座位状态和座位基础信息分开。前端先渲染静态座位图，再通过WebSocket或轮询拿到状态集合，这样用户在页面上停留时，其他人选了座，页面能实时变红，而不是等刷新才知道。

座位的坐标存储在position_x和position_y字段，单位是“格子”，前端在自适应屏幕时乘以格子宽度，就能保证不同屏幕上座位图的相对布局一致。

5.4 商家端的座位编排功能

为了不把毕设做成“用户端好看、商家端没法用”，我特意加了一个商家端座位编辑页面。商家可以选择桌型（2人桌、4人桌、包间），拖拽到座位图上，保存后生成坐标。

这个页面听起来复杂，但实现可以简化：用一个可拖拽的容器，保存时把每个座位的相对坐标提交到后端，更新seat表。要保证和用户端看到的是同一套数据，这样才能真正做到“前端所见即商家所配”。

6. 完整流程走通：从打开小程序到完成核销

6.1 首页推荐流的数据来源

用户打开小程序，首页调用/api/recommend/home，后端会根据用户身份决定返回策略。已登录用户且行为数据足够，返回Item-CF的推荐结果，否则返回热门餐厅和热门菜品组合。

这里我会在返回结构里把“推荐原因”也带上，比如“因为您浏览过水煮鱼，所以推荐水煮肉片”，用户会觉得推荐是懂他的。这部分可以直接从相似菜品列表中取一个相似度最高的做文案。

6.2 餐厅详情与场次选择

用户点击餐厅卡片，进入餐厅详情页。页面展示餐厅图片、地址、介绍、菜品列表，重点是场次信息和余票量。每个场次展示当前剩余可售票数，这个数据来源于seat_status表按场次统计空闲座位数。

余票数的计算不能实时查数据库扫描全表，我是用Redis的scard统计空闲座位集合数量，这个数值在每次座位状态变化时同步更新，保证展示延时在两秒以内。

6.3 购票选座的完整交互链路

用户选择场次后，点击“购票选座”按钮，进入选座页面。我先让用户选择就餐人数，然后高亮所有容量足够的空闲座位。用户点击座位，确认座位号，进入确认订单页。

确认订单页展示餐厅、场次、座位、已选菜品、总价。此时后端已创建“待支付”状态的订单，并锁定了该座位。页面提供15分钟倒计时，倒计时结束自动提示“订单超时已释放座位”。

这里有一个体验细节：用户在确认页修改菜品数量，不会影响座位锁定，但修改金额后需要重新计算订单金额。如果用户退出确认页，订单状态仍为“待支付”，直到超时或主动取消。

6.4 支付回调与订单幂等处理

支付环节我建议接入模拟支付，或者用支付宝沙箱环境，因为毕设演示阶段不需要真实扣款。支付回调接口是/api/pay/callback，后端依据商户订单号orderNo查询订单，判断当前状态。

如果订单状态是“待支付”，则将状态改成“已支付”，同时更新座位状态为“已售”，并将user_behavior表中插入一条购买行为数据。如果订单状态已经是“已支付”，说明回调重复，直接返回成功，不做二次处理。

这一步如果处理不好，很容易出现用户付了款但座位没锁定的问题。建议给orders表的order_no加唯一索引，并且把更新订单状态和更新座位状态放在同一个事务里。

6.5 商家核销与数据统计

用户到店后出示核销码，商家端输入核销码调用/api/verify/consume接口。后端先校验核销码是否存在，再校验订单状态是否为“已支付”，然后更新订单状态为“已核销”。

核销完成后，商家的经营看板会更新今日核销单量、入座率、菜品销售排行。这些统计数据的SQL都不复杂，按天分组聚合即可。但要注意，实时看板的数据不建议每刷新一次就全量查库，可以用定时任务把统计结果缓存到Redis，每10分钟刷新一次，页面即查即得。

7. 常见问题与排查技巧实录

7.1 座位状态不一致：缓存与数据库不同步

这个问题几乎在测试阶段必现。表现是：用户端页面显示有座位空着，但点击选座却被提示已被占用，或者反过来。

根源通常是Redis里的座位状态和数据库里的seat_status不一致。我排查这类问题时，会先写一个脚本对比两个数据源的状态，找出差异座位，再定位是哪条更新路径漏掉了缓存更新。经验是：任何修改seat_status的方法里，都必须同时更新Redis，两者通过同一个事务方法包裹，不能只改一处。

7.2 推荐算法效果不佳：数据稀疏下的相似度失真

如果整个测试阶段用户行为数据不超过几千条，Item-CF算出来的相似度会很奇怪。比如两三个用户恰好同时购买了某个菜品，系统就认为这两个菜品强相关，产生“啤酒和尿布”式的错误推荐。

解决思路有两个：第一，相似度公式里对共现次数做下限约束，两个菜品至少要同时出现3次以上才参与相似度计算；第二，把点击行为的权重调低，把购买行为的权重调高，避免偶然点击造成干扰。

7.3 并发测试下超卖：锁的粒度不够

有同学把分布式锁的key设计成整个场次，结果一个用户选座，其他所有用户都被锁住，体验很差；还有同学把锁的key设计成订单号而不是座位号，导致同一个座位两个订单同时创建。

正确做法是锁的key必须精确到 “场次+座位”，也就是lock:seat:{sessionId}:{seatId}。并发测试时可以模拟100个线程同时抢一个座位，观察最终是否只有一个订单成功，其余全部返回占用。这个测试我在项目里用Jmeter跑过，效果可靠。

7.4 移动端适配问题：不同机型坐标偏移

座位图在iPhone和Android大屏上展示差异明显，坐标写死成像素值必然出问题。我的做法是后端返回的坐标以网格为单位，前端根据屏幕宽度计算每格的实际像素，然后做等比缩放。座位图的字号和颜色可以通过CSS媒体查询适配小屏设备，但要确保座位的可点击区域不小于40x40像素。

7.5 定时任务的执行时间漂移

超时释放座位如果放在单机定时任务里，在演示环境没问题，但如果以后部署多实例，就会出现重复执行的情况。我在定时任务上用了一个分布式锁，每次执行先尝试获取lock:scan:expireOrder，获取成功才扫描，防止多个实例重复处理同一批订单。

写在最后

折腾完整个系统，我最大的体会是：毕设项目难的不是某个技术点，而是把散落的功能串成一条能自洽的业务链路。推荐算法本身写起来只有几十行，真正费精力的是行为数据从采集到落库；座位图交互也不是难点，难点是座位状态在缓存、数据库、前端页面三处保持同步。如果你也在做类似题目，我建议动手写代码之前，先把状态机画清楚，把每个状态的触发条件和入口列成表格，再开始建表。这样后面写代码，基本就是在填表。

另外一个小建议：尽量把演示环境搭得稳定一些，推荐的数据提前造好，座位演示场次的库存设高一点。答辩现场不能出“推荐接口返回空白”或者“选座被锁”这种低级问题。这个系统后续要扩展也很简单，推荐算法可以升级成混合推荐，叠加热度衰减和距离权重；座位管理可以支持包厢预定和按时段计费。把这些扩展点留在个人博客里，本身也是加分项。