跟过苍穹外卖这个 Java 项目的人都知道前面九天大多是在搭架子员工管理、分类菜品、套餐管理把这些基础接口写完系统不过是个“后台管理系统”。到了 day10 和 day11才真正进入外卖平台的命脉——用户下单、支付回调、订单状态流转、超时自动取消、商家来单提醒和用户催单。这两天的内容把整个交易闭环完整串起来了也是很多同学第一次接触 Spring Task 和 WebSocket 这两个 Spring Boot 生态里的重要组件。我见过不少同学跟到 day9 还挺顺畅一到 day10、day11 就懵了原因很简单前面 CRUD 是“照着表写接口”这两天是“带着业务流程写逻辑”要处理事务、幂等、并发、定时任务、长连接推送任何一个环节没想清楚都会出问题。这篇文章就把这两天的核心内容拆开揉碎按照从用户下单到商家接单的完整链路来讲把每个环节为什么这么做、底层原理是什么、实践里会踩哪些坑都说清楚适合正好学到这两天的同学也适合想回头补基础的人。1. 先搞清楚 day10 和 day11 到底在做什么1.1 从 CRUD 到交易闭环的转变苍穹外卖的前半段本质上是一个“管理端接口练习”员工登录、新增菜品、修改分类、套餐起售停售所有接口都是对单张表的增删改查最多加个文件上传、Redis 缓存这样的点缀。到了 day10视角突然切到“用户端”。用户端是什么小程序里的那套东西。用户打开小程序能看到店铺营业状态、浏览菜品、加购物车、提交订单、支付订单。这里涉及的表不再是单张而是订单表、订单明细表、地址簿、购物车、菜品、套餐等多张表联动。写一个下单接口等于同时操作五六张表还要保证数据一致这就不是普通 CRUD 能覆盖的了。day10 的核心是“创建订单 支付”day11 的核心是“订单支付成功后的后续处理”定时任务扫描超时未支付订单并自动取消WebSocket 把新订单实时推送给商家端用户发起催单时同样通过 WebSocket 提醒商家。所以准确说这两天的内容不能孤立看它是一个完整的交易闭环用户提交订单 → 订单创建成功待付款→ 用户支付 → 微信回调通知后端 → 订单变已付款 → 商家端实时收到新订单提醒 → 商家接单 → 用户随时可以催单 → 商家端收到催单提醒。1.2 功能地图从下单到出餐系统里发生了什么把整个流程拆成功能节点大概是这样一张表环节功能载体关键问题商品浏览用户端菜品/套餐查询接口缓存与数据库一致性购物车用户端购物车增删改查数据存储在 Redis提交订单下单接口多表事务、金额计算、库存扣减微信支付统一下单 支付回调签名验签、幂等处理超时自动取消Spring Task 定时任务扫描时间边界、恢复库存来单提醒WebSocket 服务端推送连接管理、消息格式约定用户催单WebSocket 服务端推送区分消息类型、精准发送商家接单管理端订单操作状态流转校验这张表一列出来就明白了前九天学的是“单点功能”day10、day11 学的是“链路设计”。这也是企业里真实开发中最常遇到的场景不是每个接口都是孤岛大部分接口都是在一条业务链路上扮演一个节点。1.3 为什么要用 Spring Task 和 WebSocket很多初学者第一次看到定时任务和 WebSocket会下意识觉得“这不是个外卖项目吗怎么会用到这么‘高并发’的技术”其实原因特别朴素。订单超时未支付总不能让用户手动取消吧那系统到点自动取消最直接的实现方式就是开个定时任务每分钟扫一次数据库把创建时间超过 15 分钟的“待付款”订单改成“已取消”。这就是 Spring Task 的用武之地它比 Quartz 轻量得多一个 Scheduled 注解就够了。WebSocket 同理。用户下单后商家端需要一个“实时提醒”如果用 HTTP 轮询每隔几秒请求一次“有没有新订单”不仅浪费服务器资源提醒还不实时。WebSocket 建立一条长连接服务端有新订单时主动推给浏览器体验和资源消耗都更好。这两项技术都很有代表性Spring Task 解决“到点该做事”的问题WebSocket 解决“服务端主动找客户端”的问题。搞懂了这两块以后在其他项目里遇到类似需求思路是通用的。2. 用户下单不只是往两张表里插数据2.1 下单接口的入参与出参设计下单接口的路径一般是POST /user/order/submit前端小程序提交的数据封装成一个 DTO字段大概包含这几类地址簿 ID从哪里送用户得先选收货地址。支付方式1 表示微信支付2 表示余额支付之类的实际项目里大多只做微信。预计送达时间用户选的期望时间。备注给商家的留言。打包费、餐具数量这些会影响订单金额。注意这个 DTO 里并没有购物车数据。为什么不把购物车商品也一起传过来因为购物车数据存在 Redis 里用户登录后 key 就是cart_用户id后端可以直接从 Redis 查。更重要的是商品价格、份数这些信息必须以后端数据库里的为准不能信任前端传过来的金额否则用户改个参数就能 1 分钱下单这是严重的漏洞。所以后端拿到 DTO 后的第一步是先校验地址簿和购物车是否存在然后从数据库重新查出菜品或套餐的真实价格逐项计算总金额。整个流程下来前端传过来的其实只有“用户意图”真正用于落库的数据全是后端自己查出来的。2.2 下单核心步骤拆解按照苍穹外卖的实现下单接口内部大概要干这几件事根据userId从 Redis 查询购物车数据。根据addressBookId查询地址簿确认地址存在且有效。计算订单总金额遍历购物车区分是菜品还是套餐查出单价乘以数量并累加最后加上打包费。生成订单号一般用时间戳加随机数或者干脆用雪花算法保证全局唯一且趋势递增。插入订单表orders包含订单号、用户 ID、地址 ID、金额、支付状态、下单时间等。批量插入订单明细表order_detail一条订单对应多条明细明细里冗余了菜品名、图片、价格等快照信息。清空 Redis 里的购物车。扣减对应菜品的库存或更新销量。这里面最关键的细节是第 6 步的“冗余快照”。为什么订单明细里要存菜品名称和图片因为菜品价格和名称以后可能改但用户的订单是历史事实一旦下单当时的菜品名、单价、数量就必须固定下来。这就是订单系统的“快照”思想跟拍照片一样把交易时刻的商品信息固化在订单里后续怎么改菜单都不影响历史订单展示。另外购物车中同一菜品可能加了多份Redis 里的数据结构通常是 hashfield 是菜品 IDvalue 是数量。后端遍历时要区分菜品和套餐两张表因为它们的 ID 可能重复必须用一个 type 字段区分类型不然查错表就会得到错误的价格。2.3 事务与并发这里必须认真对待下单涉及多张表的写入orders、order_detail 插入购物车删除菜品库存更新。任何一步失败都不能留下“订单创建了但明细缺失”或“购物车清空了但订单没生成”的脏数据。所以整个下单方法必须加上Transactional保证这组操作要么全部成功要么全部回滚。这里有一个初学者特别容易踩的坑事务方法自调用会失效。比如你在 Service 里写了一个私有方法 doSubmit然后在另一个方法里通过this.doSubmit()调用它Transactional 是不生效的因为 Spring 的声明式事务基于 AOP 代理只有通过代理对象调用方法代理才会拦截并开启事务。很多人下单接口偶尔出现数据不一致查了半天都是栽在这上面。再说并发。外卖系统里最典型的并发场景是“最后一份菜品被两个人同时下单”。如果只是简单地update dish set stock stock - 1 where id ?两个请求同时读到库存为 1各自减完库存变 0但实际上卖出了 2 份这就超卖了。实际项目中通常用乐观锁或悲观锁解决比如 SQL 里加条件where stock ?或者用update ... set stock stock - ? where id ? and stock ?更新的行数等于 0 就说明库存不足直接抛异常回滚事务。课堂项目里可能没做这么深但这个思路你一定得知道面试被问“超卖问题怎么解决”就是考这个。2.4 金额计算的精度细节订单金额是钱一分钱都不能差。Java 里计算金额必须用 BigDecimal绝对不能用 double 或 float。原因很简单二进制浮点数没办法精确表示 0.1比如0.1 0.2用 double 算出来是0.30000000000000004如果金额计算出现这种误差用户支付时看到的金额和数据库里的金额对不上对账时就麻烦大了。BigDecimal 用multiply做乘法时建议同时指定精度比如price.multiply(new BigDecimal(count)).setScale(2, RoundingMode.HALF_UP)四舍五入保留两位小数。数据库里的金额字段一般用 decimal(10,2)Java 实体里对应 BigDecimal。这个细节在整个订单链路里反复出现凡是涉及钱的计算一律走 BigDecimal没有例外。3. 支付回调服务端确认才是真支付3.1 微信支付的完整调用流程下单成功之后订单状态是“待付款”接下来用户要在小程序里完成支付。支付不是前端直接调微信支付接口的而是需要后端先调用微信支付的“统一下单”接口生成一个预支付交易单号再把相关参数返回给小程序端小程序端拿到参数后调用wx.requestPayment拉起支付界面。苍穹外卖项目里后端调用统一下单核心要准备这几样东西小程序 AppID、商户号、API 密钥。订单号就是刚刚下单生成的订单号。订单金额单位是分比如 25.00 元要转成 2500。回调地址 notifyUrl微信支付成功后会把结果以 POST 请求推送到这个地址。调用统一下单接口时需要对参数按照字典排序后生成签名再把签名一起发给微信服务器。这一步一旦搞错最常见的报错就是“签名错误”。很多同学在这里卡住其实是参数名写错了或者密钥配置不对没有任何技巧可言好好对文档把参数名一个个核过去。3.2 回调接口的处理逻辑与幂等支付完成之后微信服务器会主动调用我们配置的 notifyUrl把支付结果通知给后端。这个回调接口的地址通常是POST /notify/paySuccess它不经过小程序端是微信服务器直接请求后端服务。回调里包含商户订单号、微信交易号、支付金额、签名等数据。后端收到回调后的处理顺序很重要验签用 API 密钥重新生成签名和微信传来的签名对比不一致直接拒绝防止伪造回调。查询订单根据回调里的商户订单号查出订单记录确认订单确实存在。判断订单状态如果订单已经是“已付款”说明之前处理过了直接返回成功不再重复更新。更新订单状态把待付款改成已付款记录支付时间、微信交易号。返回给微信一个成功应答比如字符串SUCCESS。第 3 步就是幂等。什么叫幂等同一个请求无论执行多少次结果都一样。支付回调可能因为网络问题被微信重复推送如果后端每次收到回调都把订单改成已付款虽然结果看起来一样但重复更新会带来很多隐患比如状态字段、时间字段被刷新或者触发后续推送逻辑重复执行。正确做法是在更新前加一层状态判断where status 待付款这样只有第一次回调能成功更新后面的回调因为状态不再是待付款直接被挡在外面。我见过有同学实现回调时只做了“收到回调就更新状态”结果微信重试了几次商家端连着收到好几遍“新订单提醒”用户体验特别糟糕。所以幂等这块必须在设计回调的第一天就考虑好。3.3 回调地址外网可访问是个硬前提回调要能被微信服务器访问就必须保证回调接口部署在公网能访问的地址上。开发阶段没有服务器怎么办大多数人用的是内网穿透工具把本地服务映射成一个公网临时域名。这里要提醒一句开发环境下用临时域名没问题但要留意工具的免费版域名会变变更后记得同步修改支付配置里的 notifyUrl不然回调会突然全部失败排查半天找不到原因。另外回调接口的入参可能是 JSON 也可能是 XML取决于微信支付的接口版本。处理时建议先把这个报文原样打日志方便排查问题。我调试回调的时候日志里一定会打印原始报文、验签结果、订单号这些信息在出问题时比任何 debug 都好使。4. Spring Task系统里那些“到点自动做的事”4.1 定时任务在外卖系统里的两个经典场景Spring Task 是 Spring 框架自带的轻量级定时任务功能核心就一个注解Scheduled。苍穹外卖 day11 里定时任务主要干两件事第一件每分钟扫描一次订单表把创建时间超过 15 分钟且状态还是“待付款”的订单自动改成“已取消”。用户下单了不付钱系统不能一直等着自动取消是外卖平台的标配操作。第二件每天按固定时间修改店铺营业状态。比如凌晨 0 点店铺打烊早上 6 点自动开始营业。这两个时间点一过系统自动把 status 字段改掉不用人工干预。为什么要用定时任务而不是其他方案因为这两个业务天然就是“到点检查、到点执行”的模型用定时任务最直接。有人可能会问用户下单后我立刻开个线程 sleep 15 分钟再检查行不行理论上可以但订单量大时线程数量会爆炸而且服务重启后这些等待中的线程全都没了非常不可靠。定时任务从数据库扫描服务重启后状态还在兜底能力强得多。4.2 Cron 表达式与 Scheduled 注解Spring Task 里最常用的配置方式是在方法上加注解比如Component Slf4j public class OrderTask { Scheduled(cron 0 0/1 * * * ?) public void processTimeoutOrder() { // 定时处理超时订单 } Scheduled(cron 0 0 0 * * ?) public void closeShopByTimer() { // 店铺打烊 } }Cron 表达式的格式是秒 分 时 日 月 周这个和 Linux 的 crontab 不太一样Spring 里多了“秒”这一位而且最后一位“周”的语义也更严格。常见用法直接记几个0 0/1 * * * ?每分钟的第 0 秒执行一次也就是每分钟执行一次。0 0 0 * * ?每天 0 点执行。0 0 6 * * ?每天 6 点执行。0 15 10 * * ?每天 10 点 15 分执行。其中?表示不指定“周”的值因为“日”和“周”如果同时指定会发生冲突比如你想“每月 1 号执行”和“每周一执行”是互斥的两类需求所以 Spring 用?来忽略其中一项。写 Cron 表达式建议先在在线工具上验证一下因为表达式写错了并不报错只是任务永远不执行或者执行得莫名其妙。4.3 超时订单取消的实现细节处理超时订单的逻辑看起来简单其实有几个细节必须处理好。第一步扫描。SQL 大概是select * from orders where status ? and order_time ?这里的 status 待付款的值假设是 1订单时间要小于“当前时间减去 15 分钟”。注意这里的比较条件要用订单创建时间order_time而不是用“当前时间直接减 15 分钟”两者的差异在于如果定时任务延迟了几秒执行用创建时间判断依然精确用now() - interval 15 minute其实也差不多但语义上创建时间更准确。第二步状态流转。把查出来的订单状态从待付款改成已取消。这里同样要加条件where status 待付款防止订单在这期间已经完成了支付可能支付回调恰好在这几秒内到了结果被定时任务误取消。这个并发问题非常隐蔽但真实场景下一定存在你永远不知道用户是不是正在付款的那一瞬间被扫描到并取消。第三步恢复库存。订单取消后下单时扣减的菜品库存要加回来不然卖着卖着库存就悄悄少了。到这里你会再次体会到下单时扣库存和取消时加库存是一个配对操作只扣不加库存数据最终一定错。4.4 定时任务的坑我替你们踩过了Spring Task 默认是单线程的也就是说所有 Scheduled 方法在同一个线程里排队执行。如果某个任务执行时间很长比如扫描大量订单后面的任务就会延后。项目里任务少无所谓任务多的时候建议配置一个线程池让不同任务跑在不同线程上。还有一个坑是定时任务里如果抛出异常普通任务并不会导致整个应用挂掉但这次执行就中断了日志里如果没做好异常捕获你甚至不知道任务失败过。所以定时任务方法内部一定要 try-catch 包住核心逻辑至少把异常打到日志里方便事后排查。另外提醒一点开发环境调试定时任务时别把 Cron 表达式设成每秒执行一次然后提交代码部署上线否则生产环境数据库会被频繁扫描可能出现意料之外的压力。调试时可以临时把时间间隔改短但上线前一定还原。5. WebSocket让商家“秒知道”新订单5.1 为什么这里必须用 WebSocketHTTP 协议是“请求-响应”模式客户端不发请求服务端就没法主动给客户端发消息。商家端管理页面如果想实时知道有没有新订单最笨的办法是隔几秒发一次“有新订单吗”这叫轮询。轮询的问题很明显浪费资源、实时性差、请求频率难把握。WebSocket 不一样它通过一次 HTTP 握手建立长连接之后服务端可以随时主动把数据推给客户端客户端也能随时发给服务端双向通信。订单支付成功那一刻后端调用 WebSocket 服务给商家端浏览器推一条消息浏览器收到后立刻弹提示音、弹出新订单卡片体验跟原生 App 几乎没有差别。苍穹外卖项目里 WebSocket 的使用场景有两个一是来单提醒二是客户催单。技术上差不多区别只在推送的消息内容和接收端。5.2 WebSocket 服务端连接管理WebSocket 服务端的核心类是 WebSocketServer通过ServerEndpoint注解暴露一个 WebSocket 端点比如/ws/{sid}。这里有个概念要先搞清楚WebSocket 连接是有状态的服务端必须管理好当前所有客户端的连接会话。常见的做法是在内存里放一个ConcurrentHashMapString, Sessionkey 是客户端的标识value 是 WebSocket 的 Session 对象。用户上线时onOpen把 session 放进去断开时onClose移除。为什么用 ConcurrentHashMap因为 WebSocket 的 onOpen 和 onClose 可能由不同线程触发普通 HashMap 在多线程环境下可能死循环或丢数据ConcurrentHashMap 是线程安全的。如果只有一个商家端管理页面用全局连接就够了推送时遍历所有 session 发送。但系统里还有用户端小程序小程序一般不直接维护 WebSocket 长连接催单是通过 HTTP 接口触发后由后端转发推送给商家端浏览器的。所以推送逻辑要分清“谁接收”消息里带上 type 字段前端根据 type 决定展示方式。5.3 来单提醒和催单的消息设计来单提醒的流程是用户支付成功支付回调里更新订单状态为已付款后紧接着调用 WebSocket 推送方法向商家端推送一条类似这样的消息{ type: 1, orderId: 12345, userId: 用户标识, message: 您有新的订单 }商家端页面收到 type 为 1 的消息就知道来新订单了弹窗、播放提示音、刷新订单列表。催单的流程是用户在小程序里点击“催单”后端收到催单请求后先检查订单是否存在、状态是否合理比如已接单但未完成然后通过 WebSocket 给商家端推一条 type 为 2 的消息内容包含订单号和提示语。商家端浏览器收到 type 2 的消息后可以弹出一个醒目的催单提示提醒商家赶紧出餐。这里最关键的设计在于 type 字段。如果所有消息都用一个模糊的 JSON 字符串前端每收到一条消息都不知道该怎么处理。约定好消息类型前端才能做差异化响应这个约定本质上就是一种简单的“应用层协议”。真实项目中还会加 messageId、时间戳等字段用于消息去重和追踪课堂项目做到 type 业务字段这个程度已经够用。5.4 WebSocket 落地时的几个抓狂问题第一个坑是连接建立后onOpen 里拿不到登录用户信息。WebSocket 握手时走的虽然是 HTTP 协议但默认情况下后端在 onOpen 方法里通过 HttpSession 拿不到用户因为 WebSocket 端点对象不是 Spring 管理的也不在 Servlet 容器的作用域里。苍穹外卖的解决办法是在握手阶段通过拦截器获取或者干脆在连接路径上带上用户标识比如/ws/{sid}这个 sid 可以编码用户 ID服务端从 URL 里解析出来再做身份验证。第二个坑是 Session 的线程安全问题。WebSocket 的 Session 不能被多个线程同时写不然会出现奇怪的数据错乱实际开发中发送消息基本都在业务线程里执行和 WebSocket 的接收线程是不通的所以发送时要做同步控制比如用synchronized(session)包住 send 方法。第三个坑是连接断开。用户关了浏览器或者网络切换onClose 可能不会立刻触发服务端这边 session 还留在 Map 里推送时会报错。要么在发送时捕获异常并移除失效 session要么定时发心跳检测连接是否还活着。课堂项目里一般用发送时捕获异常处理就够了但你要知道这个问题的存在。6. 常见问题与排查手记6.1 问题速查表把这两天最容易踩的问题整理成一个速查表遇到问题先对着查。现象可能原因排查方向下单后订单表没数据事务回滚了看异常日志检查购物车是否为空、地址是否缺失下单后购物车没清空清空操作在事务中被回滚检查清空逻辑是否在订单插入之后、确认事务边界库存越扣越少取消订单时没恢复库存检查超时取消和退款流程里的库存回补逻辑支付回调一直收不到notifyUrl 不可访问确认外网可达查看回调日志有没有请求进来支付回调验签失败密钥配置错误或参数名不一致打印原始报文按文档核对签名算法同一订单被重复处理回调缺少幂等判断在更新语句里加where status 待付款条件定时任务不执行Cron 表达式写错用在线 Cron 工具验证表达式定时任务执行多次多个实例都跑了任务生产环境注意分布式锁开发环境关掉多余实例WebSocket 连不上握手路径或跨域配置错误看浏览器 Network 里的 WS 握手状态码新订单商家端没提示推送时 Session 已经失效发送时捕获异常移除失效的 session催单商家端没收到消息 type 不匹配检查前端处理逻辑里对 type 的约定6.2 两个真实排查过程的思路分享有一个典型场景支付成功后订单状态一直没变。很多人第一反应是“回调接口出问题了”但排查下来 notifyUrl 能访问、日志里也有微信的回调记录最后发现是回调解析报文时字段名大小写没对上导致查订单号查出来的是 null更新语句直接没执行。这个问题的解决思路是先确认“微信到底有没有调我们”再看“我们的代码有没有真的执行到”最后看“执行过程中有没有报错”。三步排查层层递进比瞎猜有效得多。还有一个场景商家端页面偶尔收不到新订单提醒。原因出在页面上有两个 TabWebSocket 在某个 Tab 里被初始化了一次用户切换 Tab 后那个 Tab 被浏览器回收WebSocket 连接断开了但服务端的旧 session 还没被清理。服务端推送时拿着旧 session 发送发现连接已关闭才报错此时再移除旧 session 已经晚了消息已经丢了。这个问题的解决方案是服务端推送统一走一个方法发送失败就移除 session同时前端在页面重新可见时主动重连 WebSocket保证连接不长期失效。6.3 这两天的内容实操时建议做三件事第一把下单、支付回调、超时取消这三段代码的日志打完整。日志里必须有订单号、状态变化、金额这几个关键字段一旦出问题靠日志就能还原整条链路。第二自己把订单状态流转画一张图。从待付款到已付款、已接单、配送中、已完成、已取消每个状态之间有哪些合法跳转哪个操作触发跳转画明白这张图订单模块的代码你就能真正掌握。第三把 WebSocket 的消息格式固定下来。以后扩展新消息类型比如“退款提醒”“平台通知”只需要增加 type 的值后端推送和前端处理都按同一个约定扩展不会越改越乱。我在实际跟这个项目的时候最大的体会是这两天的代码量不算特别大但每个环节背后都藏着“为什么”。为什么下单要加事务为什么回调要幂等为什么定时任务要扫描而不是 sleep为什么推送要用 WebSocket 而不是轮询把这些为什么想明白了你收获的就不是两天代码而是一整套交易系统的通用设计能力。后面不管换什么项目这些思路都能直接复用这才是 day10 和 day11 真正值钱的地方。
跟过苍穹外卖这个 Java 项目的人都知道前面九天大多是在搭架子员工管理、分类菜品、套餐管理把这些基础接口写完系统不过是个“后台管理系统”。到了 day10 和 day11才真正进入外卖平台的命脉——用户下单、支付回调、订单状态流转、超时自动取消、商家来单提醒和用户催单。这两天的内容把整个交易闭环完整串起来了也是很多同学第一次接触 Spring Task 和 WebSocket 这两个 Spring Boot 生态里的重要组件。我见过不少同学跟到 day9 还挺顺畅一到 day10、day11 就懵了原因很简单前面 CRUD 是“照着表写接口”这两天是“带着业务流程写逻辑”要处理事务、幂等、并发、定时任务、长连接推送任何一个环节没想清楚都会出问题。这篇文章就把这两天的核心内容拆开揉碎按照从用户下单到商家接单的完整链路来讲把每个环节为什么这么做、底层原理是什么、实践里会踩哪些坑都说清楚适合正好学到这两天的同学也适合想回头补基础的人。1. 先搞清楚 day10 和 day11 到底在做什么1.1 从 CRUD 到交易闭环的转变苍穹外卖的前半段本质上是一个“管理端接口练习”员工登录、新增菜品、修改分类、套餐起售停售所有接口都是对单张表的增删改查最多加个文件上传、Redis 缓存这样的点缀。到了 day10视角突然切到“用户端”。用户端是什么小程序里的那套东西。用户打开小程序能看到店铺营业状态、浏览菜品、加购物车、提交订单、支付订单。这里涉及的表不再是单张而是订单表、订单明细表、地址簿、购物车、菜品、套餐等多张表联动。写一个下单接口等于同时操作五六张表还要保证数据一致这就不是普通 CRUD 能覆盖的了。day10 的核心是“创建订单 支付”day11 的核心是“订单支付成功后的后续处理”定时任务扫描超时未支付订单并自动取消WebSocket 把新订单实时推送给商家端用户发起催单时同样通过 WebSocket 提醒商家。所以准确说这两天的内容不能孤立看它是一个完整的交易闭环用户提交订单 → 订单创建成功待付款→ 用户支付 → 微信回调通知后端 → 订单变已付款 → 商家端实时收到新订单提醒 → 商家接单 → 用户随时可以催单 → 商家端收到催单提醒。1.2 功能地图从下单到出餐系统里发生了什么把整个流程拆成功能节点大概是这样一张表环节功能载体关键问题商品浏览用户端菜品/套餐查询接口缓存与数据库一致性购物车用户端购物车增删改查数据存储在 Redis提交订单下单接口多表事务、金额计算、库存扣减微信支付统一下单 支付回调签名验签、幂等处理超时自动取消Spring Task 定时任务扫描时间边界、恢复库存来单提醒WebSocket 服务端推送连接管理、消息格式约定用户催单WebSocket 服务端推送区分消息类型、精准发送商家接单管理端订单操作状态流转校验这张表一列出来就明白了前九天学的是“单点功能”day10、day11 学的是“链路设计”。这也是企业里真实开发中最常遇到的场景不是每个接口都是孤岛大部分接口都是在一条业务链路上扮演一个节点。1.3 为什么要用 Spring Task 和 WebSocket很多初学者第一次看到定时任务和 WebSocket会下意识觉得“这不是个外卖项目吗怎么会用到这么‘高并发’的技术”其实原因特别朴素。订单超时未支付总不能让用户手动取消吧那系统到点自动取消最直接的实现方式就是开个定时任务每分钟扫一次数据库把创建时间超过 15 分钟的“待付款”订单改成“已取消”。这就是 Spring Task 的用武之地它比 Quartz 轻量得多一个 Scheduled 注解就够了。WebSocket 同理。用户下单后商家端需要一个“实时提醒”如果用 HTTP 轮询每隔几秒请求一次“有没有新订单”不仅浪费服务器资源提醒还不实时。WebSocket 建立一条长连接服务端有新订单时主动推给浏览器体验和资源消耗都更好。这两项技术都很有代表性Spring Task 解决“到点该做事”的问题WebSocket 解决“服务端主动找客户端”的问题。搞懂了这两块以后在其他项目里遇到类似需求思路是通用的。2. 用户下单不只是往两张表里插数据2.1 下单接口的入参与出参设计下单接口的路径一般是POST /user/order/submit前端小程序提交的数据封装成一个 DTO字段大概包含这几类地址簿 ID从哪里送用户得先选收货地址。支付方式1 表示微信支付2 表示余额支付之类的实际项目里大多只做微信。预计送达时间用户选的期望时间。备注给商家的留言。打包费、餐具数量这些会影响订单金额。注意这个 DTO 里并没有购物车数据。为什么不把购物车商品也一起传过来因为购物车数据存在 Redis 里用户登录后 key 就是cart_用户id后端可以直接从 Redis 查。更重要的是商品价格、份数这些信息必须以后端数据库里的为准不能信任前端传过来的金额否则用户改个参数就能 1 分钱下单这是严重的漏洞。所以后端拿到 DTO 后的第一步是先校验地址簿和购物车是否存在然后从数据库重新查出菜品或套餐的真实价格逐项计算总金额。整个流程下来前端传过来的其实只有“用户意图”真正用于落库的数据全是后端自己查出来的。2.2 下单核心步骤拆解按照苍穹外卖的实现下单接口内部大概要干这几件事根据userId从 Redis 查询购物车数据。根据addressBookId查询地址簿确认地址存在且有效。计算订单总金额遍历购物车区分是菜品还是套餐查出单价乘以数量并累加最后加上打包费。生成订单号一般用时间戳加随机数或者干脆用雪花算法保证全局唯一且趋势递增。插入订单表orders包含订单号、用户 ID、地址 ID、金额、支付状态、下单时间等。批量插入订单明细表order_detail一条订单对应多条明细明细里冗余了菜品名、图片、价格等快照信息。清空 Redis 里的购物车。扣减对应菜品的库存或更新销量。这里面最关键的细节是第 6 步的“冗余快照”。为什么订单明细里要存菜品名称和图片因为菜品价格和名称以后可能改但用户的订单是历史事实一旦下单当时的菜品名、单价、数量就必须固定下来。这就是订单系统的“快照”思想跟拍照片一样把交易时刻的商品信息固化在订单里后续怎么改菜单都不影响历史订单展示。另外购物车中同一菜品可能加了多份Redis 里的数据结构通常是 hashfield 是菜品 IDvalue 是数量。后端遍历时要区分菜品和套餐两张表因为它们的 ID 可能重复必须用一个 type 字段区分类型不然查错表就会得到错误的价格。2.3 事务与并发这里必须认真对待下单涉及多张表的写入orders、order_detail 插入购物车删除菜品库存更新。任何一步失败都不能留下“订单创建了但明细缺失”或“购物车清空了但订单没生成”的脏数据。所以整个下单方法必须加上Transactional保证这组操作要么全部成功要么全部回滚。这里有一个初学者特别容易踩的坑事务方法自调用会失效。比如你在 Service 里写了一个私有方法 doSubmit然后在另一个方法里通过this.doSubmit()调用它Transactional 是不生效的因为 Spring 的声明式事务基于 AOP 代理只有通过代理对象调用方法代理才会拦截并开启事务。很多人下单接口偶尔出现数据不一致查了半天都是栽在这上面。再说并发。外卖系统里最典型的并发场景是“最后一份菜品被两个人同时下单”。如果只是简单地update dish set stock stock - 1 where id ?两个请求同时读到库存为 1各自减完库存变 0但实际上卖出了 2 份这就超卖了。实际项目中通常用乐观锁或悲观锁解决比如 SQL 里加条件where stock ?或者用update ... set stock stock - ? where id ? and stock ?更新的行数等于 0 就说明库存不足直接抛异常回滚事务。课堂项目里可能没做这么深但这个思路你一定得知道面试被问“超卖问题怎么解决”就是考这个。2.4 金额计算的精度细节订单金额是钱一分钱都不能差。Java 里计算金额必须用 BigDecimal绝对不能用 double 或 float。原因很简单二进制浮点数没办法精确表示 0.1比如0.1 0.2用 double 算出来是0.30000000000000004如果金额计算出现这种误差用户支付时看到的金额和数据库里的金额对不上对账时就麻烦大了。BigDecimal 用multiply做乘法时建议同时指定精度比如price.multiply(new BigDecimal(count)).setScale(2, RoundingMode.HALF_UP)四舍五入保留两位小数。数据库里的金额字段一般用 decimal(10,2)Java 实体里对应 BigDecimal。这个细节在整个订单链路里反复出现凡是涉及钱的计算一律走 BigDecimal没有例外。3. 支付回调服务端确认才是真支付3.1 微信支付的完整调用流程下单成功之后订单状态是“待付款”接下来用户要在小程序里完成支付。支付不是前端直接调微信支付接口的而是需要后端先调用微信支付的“统一下单”接口生成一个预支付交易单号再把相关参数返回给小程序端小程序端拿到参数后调用wx.requestPayment拉起支付界面。苍穹外卖项目里后端调用统一下单核心要准备这几样东西小程序 AppID、商户号、API 密钥。订单号就是刚刚下单生成的订单号。订单金额单位是分比如 25.00 元要转成 2500。回调地址 notifyUrl微信支付成功后会把结果以 POST 请求推送到这个地址。调用统一下单接口时需要对参数按照字典排序后生成签名再把签名一起发给微信服务器。这一步一旦搞错最常见的报错就是“签名错误”。很多同学在这里卡住其实是参数名写错了或者密钥配置不对没有任何技巧可言好好对文档把参数名一个个核过去。3.2 回调接口的处理逻辑与幂等支付完成之后微信服务器会主动调用我们配置的 notifyUrl把支付结果通知给后端。这个回调接口的地址通常是POST /notify/paySuccess它不经过小程序端是微信服务器直接请求后端服务。回调里包含商户订单号、微信交易号、支付金额、签名等数据。后端收到回调后的处理顺序很重要验签用 API 密钥重新生成签名和微信传来的签名对比不一致直接拒绝防止伪造回调。查询订单根据回调里的商户订单号查出订单记录确认订单确实存在。判断订单状态如果订单已经是“已付款”说明之前处理过了直接返回成功不再重复更新。更新订单状态把待付款改成已付款记录支付时间、微信交易号。返回给微信一个成功应答比如字符串SUCCESS。第 3 步就是幂等。什么叫幂等同一个请求无论执行多少次结果都一样。支付回调可能因为网络问题被微信重复推送如果后端每次收到回调都把订单改成已付款虽然结果看起来一样但重复更新会带来很多隐患比如状态字段、时间字段被刷新或者触发后续推送逻辑重复执行。正确做法是在更新前加一层状态判断where status 待付款这样只有第一次回调能成功更新后面的回调因为状态不再是待付款直接被挡在外面。我见过有同学实现回调时只做了“收到回调就更新状态”结果微信重试了几次商家端连着收到好几遍“新订单提醒”用户体验特别糟糕。所以幂等这块必须在设计回调的第一天就考虑好。3.3 回调地址外网可访问是个硬前提回调要能被微信服务器访问就必须保证回调接口部署在公网能访问的地址上。开发阶段没有服务器怎么办大多数人用的是内网穿透工具把本地服务映射成一个公网临时域名。这里要提醒一句开发环境下用临时域名没问题但要留意工具的免费版域名会变变更后记得同步修改支付配置里的 notifyUrl不然回调会突然全部失败排查半天找不到原因。另外回调接口的入参可能是 JSON 也可能是 XML取决于微信支付的接口版本。处理时建议先把这个报文原样打日志方便排查问题。我调试回调的时候日志里一定会打印原始报文、验签结果、订单号这些信息在出问题时比任何 debug 都好使。4. Spring Task系统里那些“到点自动做的事”4.1 定时任务在外卖系统里的两个经典场景Spring Task 是 Spring 框架自带的轻量级定时任务功能核心就一个注解Scheduled。苍穹外卖 day11 里定时任务主要干两件事第一件每分钟扫描一次订单表把创建时间超过 15 分钟且状态还是“待付款”的订单自动改成“已取消”。用户下单了不付钱系统不能一直等着自动取消是外卖平台的标配操作。第二件每天按固定时间修改店铺营业状态。比如凌晨 0 点店铺打烊早上 6 点自动开始营业。这两个时间点一过系统自动把 status 字段改掉不用人工干预。为什么要用定时任务而不是其他方案因为这两个业务天然就是“到点检查、到点执行”的模型用定时任务最直接。有人可能会问用户下单后我立刻开个线程 sleep 15 分钟再检查行不行理论上可以但订单量大时线程数量会爆炸而且服务重启后这些等待中的线程全都没了非常不可靠。定时任务从数据库扫描服务重启后状态还在兜底能力强得多。4.2 Cron 表达式与 Scheduled 注解Spring Task 里最常用的配置方式是在方法上加注解比如Component Slf4j public class OrderTask { Scheduled(cron 0 0/1 * * * ?) public void processTimeoutOrder() { // 定时处理超时订单 } Scheduled(cron 0 0 0 * * ?) public void closeShopByTimer() { // 店铺打烊 } }Cron 表达式的格式是秒 分 时 日 月 周这个和 Linux 的 crontab 不太一样Spring 里多了“秒”这一位而且最后一位“周”的语义也更严格。常见用法直接记几个0 0/1 * * * ?每分钟的第 0 秒执行一次也就是每分钟执行一次。0 0 0 * * ?每天 0 点执行。0 0 6 * * ?每天 6 点执行。0 15 10 * * ?每天 10 点 15 分执行。其中?表示不指定“周”的值因为“日”和“周”如果同时指定会发生冲突比如你想“每月 1 号执行”和“每周一执行”是互斥的两类需求所以 Spring 用?来忽略其中一项。写 Cron 表达式建议先在在线工具上验证一下因为表达式写错了并不报错只是任务永远不执行或者执行得莫名其妙。4.3 超时订单取消的实现细节处理超时订单的逻辑看起来简单其实有几个细节必须处理好。第一步扫描。SQL 大概是select * from orders where status ? and order_time ?这里的 status 待付款的值假设是 1订单时间要小于“当前时间减去 15 分钟”。注意这里的比较条件要用订单创建时间order_time而不是用“当前时间直接减 15 分钟”两者的差异在于如果定时任务延迟了几秒执行用创建时间判断依然精确用now() - interval 15 minute其实也差不多但语义上创建时间更准确。第二步状态流转。把查出来的订单状态从待付款改成已取消。这里同样要加条件where status 待付款防止订单在这期间已经完成了支付可能支付回调恰好在这几秒内到了结果被定时任务误取消。这个并发问题非常隐蔽但真实场景下一定存在你永远不知道用户是不是正在付款的那一瞬间被扫描到并取消。第三步恢复库存。订单取消后下单时扣减的菜品库存要加回来不然卖着卖着库存就悄悄少了。到这里你会再次体会到下单时扣库存和取消时加库存是一个配对操作只扣不加库存数据最终一定错。4.4 定时任务的坑我替你们踩过了Spring Task 默认是单线程的也就是说所有 Scheduled 方法在同一个线程里排队执行。如果某个任务执行时间很长比如扫描大量订单后面的任务就会延后。项目里任务少无所谓任务多的时候建议配置一个线程池让不同任务跑在不同线程上。还有一个坑是定时任务里如果抛出异常普通任务并不会导致整个应用挂掉但这次执行就中断了日志里如果没做好异常捕获你甚至不知道任务失败过。所以定时任务方法内部一定要 try-catch 包住核心逻辑至少把异常打到日志里方便事后排查。另外提醒一点开发环境调试定时任务时别把 Cron 表达式设成每秒执行一次然后提交代码部署上线否则生产环境数据库会被频繁扫描可能出现意料之外的压力。调试时可以临时把时间间隔改短但上线前一定还原。5. WebSocket让商家“秒知道”新订单5.1 为什么这里必须用 WebSocketHTTP 协议是“请求-响应”模式客户端不发请求服务端就没法主动给客户端发消息。商家端管理页面如果想实时知道有没有新订单最笨的办法是隔几秒发一次“有新订单吗”这叫轮询。轮询的问题很明显浪费资源、实时性差、请求频率难把握。WebSocket 不一样它通过一次 HTTP 握手建立长连接之后服务端可以随时主动把数据推给客户端客户端也能随时发给服务端双向通信。订单支付成功那一刻后端调用 WebSocket 服务给商家端浏览器推一条消息浏览器收到后立刻弹提示音、弹出新订单卡片体验跟原生 App 几乎没有差别。苍穹外卖项目里 WebSocket 的使用场景有两个一是来单提醒二是客户催单。技术上差不多区别只在推送的消息内容和接收端。5.2 WebSocket 服务端连接管理WebSocket 服务端的核心类是 WebSocketServer通过ServerEndpoint注解暴露一个 WebSocket 端点比如/ws/{sid}。这里有个概念要先搞清楚WebSocket 连接是有状态的服务端必须管理好当前所有客户端的连接会话。常见的做法是在内存里放一个ConcurrentHashMapString, Sessionkey 是客户端的标识value 是 WebSocket 的 Session 对象。用户上线时onOpen把 session 放进去断开时onClose移除。为什么用 ConcurrentHashMap因为 WebSocket 的 onOpen 和 onClose 可能由不同线程触发普通 HashMap 在多线程环境下可能死循环或丢数据ConcurrentHashMap 是线程安全的。如果只有一个商家端管理页面用全局连接就够了推送时遍历所有 session 发送。但系统里还有用户端小程序小程序一般不直接维护 WebSocket 长连接催单是通过 HTTP 接口触发后由后端转发推送给商家端浏览器的。所以推送逻辑要分清“谁接收”消息里带上 type 字段前端根据 type 决定展示方式。5.3 来单提醒和催单的消息设计来单提醒的流程是用户支付成功支付回调里更新订单状态为已付款后紧接着调用 WebSocket 推送方法向商家端推送一条类似这样的消息{ type: 1, orderId: 12345, userId: 用户标识, message: 您有新的订单 }商家端页面收到 type 为 1 的消息就知道来新订单了弹窗、播放提示音、刷新订单列表。催单的流程是用户在小程序里点击“催单”后端收到催单请求后先检查订单是否存在、状态是否合理比如已接单但未完成然后通过 WebSocket 给商家端推一条 type 为 2 的消息内容包含订单号和提示语。商家端浏览器收到 type 2 的消息后可以弹出一个醒目的催单提示提醒商家赶紧出餐。这里最关键的设计在于 type 字段。如果所有消息都用一个模糊的 JSON 字符串前端每收到一条消息都不知道该怎么处理。约定好消息类型前端才能做差异化响应这个约定本质上就是一种简单的“应用层协议”。真实项目中还会加 messageId、时间戳等字段用于消息去重和追踪课堂项目做到 type 业务字段这个程度已经够用。5.4 WebSocket 落地时的几个抓狂问题第一个坑是连接建立后onOpen 里拿不到登录用户信息。WebSocket 握手时走的虽然是 HTTP 协议但默认情况下后端在 onOpen 方法里通过 HttpSession 拿不到用户因为 WebSocket 端点对象不是 Spring 管理的也不在 Servlet 容器的作用域里。苍穹外卖的解决办法是在握手阶段通过拦截器获取或者干脆在连接路径上带上用户标识比如/ws/{sid}这个 sid 可以编码用户 ID服务端从 URL 里解析出来再做身份验证。第二个坑是 Session 的线程安全问题。WebSocket 的 Session 不能被多个线程同时写不然会出现奇怪的数据错乱实际开发中发送消息基本都在业务线程里执行和 WebSocket 的接收线程是不通的所以发送时要做同步控制比如用synchronized(session)包住 send 方法。第三个坑是连接断开。用户关了浏览器或者网络切换onClose 可能不会立刻触发服务端这边 session 还留在 Map 里推送时会报错。要么在发送时捕获异常并移除失效 session要么定时发心跳检测连接是否还活着。课堂项目里一般用发送时捕获异常处理就够了但你要知道这个问题的存在。6. 常见问题与排查手记6.1 问题速查表把这两天最容易踩的问题整理成一个速查表遇到问题先对着查。现象可能原因排查方向下单后订单表没数据事务回滚了看异常日志检查购物车是否为空、地址是否缺失下单后购物车没清空清空操作在事务中被回滚检查清空逻辑是否在订单插入之后、确认事务边界库存越扣越少取消订单时没恢复库存检查超时取消和退款流程里的库存回补逻辑支付回调一直收不到notifyUrl 不可访问确认外网可达查看回调日志有没有请求进来支付回调验签失败密钥配置错误或参数名不一致打印原始报文按文档核对签名算法同一订单被重复处理回调缺少幂等判断在更新语句里加where status 待付款条件定时任务不执行Cron 表达式写错用在线 Cron 工具验证表达式定时任务执行多次多个实例都跑了任务生产环境注意分布式锁开发环境关掉多余实例WebSocket 连不上握手路径或跨域配置错误看浏览器 Network 里的 WS 握手状态码新订单商家端没提示推送时 Session 已经失效发送时捕获异常移除失效的 session催单商家端没收到消息 type 不匹配检查前端处理逻辑里对 type 的约定6.2 两个真实排查过程的思路分享有一个典型场景支付成功后订单状态一直没变。很多人第一反应是“回调接口出问题了”但排查下来 notifyUrl 能访问、日志里也有微信的回调记录最后发现是回调解析报文时字段名大小写没对上导致查订单号查出来的是 null更新语句直接没执行。这个问题的解决思路是先确认“微信到底有没有调我们”再看“我们的代码有没有真的执行到”最后看“执行过程中有没有报错”。三步排查层层递进比瞎猜有效得多。还有一个场景商家端页面偶尔收不到新订单提醒。原因出在页面上有两个 TabWebSocket 在某个 Tab 里被初始化了一次用户切换 Tab 后那个 Tab 被浏览器回收WebSocket 连接断开了但服务端的旧 session 还没被清理。服务端推送时拿着旧 session 发送发现连接已关闭才报错此时再移除旧 session 已经晚了消息已经丢了。这个问题的解决方案是服务端推送统一走一个方法发送失败就移除 session同时前端在页面重新可见时主动重连 WebSocket保证连接不长期失效。6.3 这两天的内容实操时建议做三件事第一把下单、支付回调、超时取消这三段代码的日志打完整。日志里必须有订单号、状态变化、金额这几个关键字段一旦出问题靠日志就能还原整条链路。第二自己把订单状态流转画一张图。从待付款到已付款、已接单、配送中、已完成、已取消每个状态之间有哪些合法跳转哪个操作触发跳转画明白这张图订单模块的代码你就能真正掌握。第三把 WebSocket 的消息格式固定下来。以后扩展新消息类型比如“退款提醒”“平台通知”只需要增加 type 的值后端推送和前端处理都按同一个约定扩展不会越改越乱。我在实际跟这个项目的时候最大的体会是这两天的代码量不算特别大但每个环节背后都藏着“为什么”。为什么下单要加事务为什么回调要幂等为什么定时任务要扫描而不是 sleep为什么推送要用 WebSocket 而不是轮询把这些为什么想明白了你收获的就不是两天代码而是一整套交易系统的通用设计能力。后面不管换什么项目这些思路都能直接复用这才是 day10 和 day11 真正值钱的地方。
