苍穹外卖实战：Spring Task与WebSocket实现智能来单催单机制
订单系统的实时性与一致性挑战
在现代外卖平台的后端架构中，订单系统承担着最核心的业务逻辑。对于开发者而言，订单系统往往隐藏着两类极易被忽视却至关重要的功能需求。第一类是状态的时间敏感性，例如用户下单后长时间未支付，系统必须在特定时间窗口后自动取消订单，释放库存资源；第二类是信息的即时性，当商家管理端页面处于打开状态时，新订单的到达或用户的催单行为需要瞬间触达，而非等待下一次HTTP轮询。前者依赖于服务端的时间调度能力，后者则依赖于双向实时通信机制。本文将以苍穹外卖项目为例，深入剖析如何利用Spring Task实现订单状态的自动化流转，以及如何通过WebSocket构建低延迟的消息推送通道，最终实现流畅的来单与催单提醒体验。
Spring Task实现订单状态的自动化流转
Spring Task是Spring Framework内置的任务调度模块，它提供了一种轻量级的方式来执行周期性或定时的后台任务。在订单业务中，处理超时订单是保证数据一致性和资源有效性的关键。Spring Task支持多种调度模式，包括Cron表达式、固定速率（fixedRate）和固定延迟（fixedDelay）。对于外卖这类强时间敏感的业务，Cron表达式因其直观的可读性和灵活性，成为首选方案。
要启用Spring Task的调度功能，必须在Spring Boot的主启动类或配置类上添加@EnableScheduling注解。这一注解会触发Spring内部对定时任务组件的扫描和注册。若遗漏此配置，即使业务代码中正确标注了@Scheduled注解，定时任务也不会被执行。在苍穹外卖项目中，订单处理逻辑被封装在OrderTask组件中，通过注入OrderMapper与数据库交互。
以取消超时未支付订单为例，定时任务每分钟执行一次（Cron表达式为0 * * * * ?）。任务执行时，首先计算十五分钟前的时间戳，随后查询数据库中状态为“待支付”且创建时间早于该时间戳的订单列表。对于查询到的每一笔订单，系统将其状态更新为“已取消”，并记录取消原因及取消时间。这种兜底机制确保了即使用户关闭浏览器或网络中断，订单数据也能在服务器端得到正确的状态修正，避免形成数据死锁或资源占用。
此外，对于长时间未配送的订单，通常设置为每日凌晨执行一次全量扫描或清理任务。在实际开发中，验证定时任务的最佳方式是临时修改Cron表达式为高频触发（如每5秒），并通过构造测试数据进行观察。验证无误后，务必恢复为符合业务逻辑的正式Cron表达式，以防止对数据库造成不必要的压力。若任务未执行，需优先排查启动类配置、组件扫描范围以及Cron表达式的语法正确性。
WebSocket构建实时通信通道
传统的HTTP请求-响应模式是单向的，客户端发起请求，服务端返回响应。这种模式在处理实时性要求高的场景时存在天然缺陷，例如商家需要即时获知新订单，若采用轮询机制，不仅造成带宽浪费，还难以保证低延迟。WebSocket协议在此基础上建立了一条持久化的全双工通信通道，允许服务端主动向客户端推送消息，完美契合来单提醒和催单通知的业务场景。
在Spring Boot中集成WebSocket，通常需要引入spring-boot-starter-websocket依赖，并配置ServerEndpointExporter Bean。该Bean负责注册由@ServerEndpoint注解标记的WebSocket端点。苍穹外卖项目中，端点路径设计为/ws/{sid}，其中sid用于唯一标识客户端的浏览器会话，便于服务端进行会话管理。
WebSocketServer组件维护了一个ConcurrentHashMap类型的sessionMap，用于存储所有在线的Session对象。当客户端成功建立连接时，onOpen方法会将sid与Session存入Map；当连接断开时，onClose方法则将其移除。这种线程安全的集合结构能够有效应对高并发下的连接建立与关闭操作。sendToAllClient方法实现了消息的群发逻辑，遍历当前所有在线Session，调用sendText方法将JSON格式的消息推送给每一个客户端。需要注意的是，该实现采用的是无差别群发策略，适用于单门店或单账号的管理场景。在多门店、多角色的复杂系统中，应根据门店ID、员工ID等维度对Session进行分组管理，以实现精准的消息推送，避免无关人员受到干扰。
支付成功后的来单提醒机制
订单提醒的触发时机至关重要。在用户提交订单后，真正的商业动作发生在支付成功之时。苍穹外卖项目中，支付成功回调接口paySuccess不仅负责更新订单状态为“待接单”和“已支付”，还负责触发WebSocket消息推送。在更新数据库之前，系统构造了一个包含type、orderId和content字段的Map对象，并将其序列化为JSON字符串。
消息类型type被定义为1，代表“来单提醒”。这种类型化设计使得前端能够根据不同的消息类型执行不同的逻辑处理。例如，type=1时播放来单铃声并弹窗提示新订单；type=2时播放催单铃声并提示用户催单。在推送消息前，务必先完成订单状态的更新，以确保管理端接收到提醒后，查询订单详情时能获取到最新的状态，避免状态不一致带来的用户体验问题。
用户催单与消息类型区分
除了来单提醒，用户催单是另一个高频交互场景。苍穹外卖提供了/user/order/reminder/{id}接口供用户发起催单。该接口首先校验订单是否存在且状态合法，随后组装包含type=2的消息并通过WebSocket群发。来单与催单复用同一条WebSocket长连接，通过type字段进行区分，这种设计简化了前端的连接维护逻辑，提高了系统的可维护性。
在实现催单逻辑时，业务校验不容忽视。除了检查订单是否存在，还应校验订单的归属权（确保用户催的是自己的订单）以及订单的可催单状态（如已完成或已取消的订单不应支持催单）。这些校验细节虽然微小，却是构建健壮业务系统的关键。通过type字段的复用，前端只需监听onmessage事件，解析type值即可决定播放何种铃声或展示何种文案，实现了逻辑的解耦与复用。
管理端接收消息与音频播放策略
在后端完成消息推送后，前端管理端的接收与处理逻辑同样重要。管理端页面通过JavaScript创建WebSocket连接，并注册onmessage事件监听器。当收到消息时，解析JSON数据，根据type值执行相应的操作。对于type=1（来单），播放order.mp3音频；对于type=2（催单），播放reminder.mp3音频。
音频播放的实现细节决定了用户体验的流畅度。每次播放前，将音频的currentTime重置为0，以确保连续来单时铃声能从开头播放，起到足够的提醒作用。然而，现代浏览器出于防止网页滥用音频资源的考虑，通常默认拦截没有用户交互的自动播放行为。因此，在管理端首次加载或用户点击“开启提醒”按钮时，必须触发一次用户交互事件（如点击），随后立即调用play()和pause()，浏览器便会授予该音频元素后续的自动播放权限。此外，在生产环境中，若网站启用HTTPS，WebSocket连接协议必须升级为wss://，否则浏览器将拦截混合内容请求，导致连接失败。前端代码还应包含断线重连机制，如onclose事件中设置定时器重新连接，以确保通信链路的稳定性。
端到端链路排查与优化
从用户支付成功到管理端铃声响起的完整链路涉及多个环节，任何一环出错都可能导致提醒失效。排查思路应遵循数据流向：首先确认数据库中订单状态是否已更新为“待接单”；其次检查服务端日志，确认WebSocketServer是否成功获取到在线Session并执行了推送；再次查看前端控制台，确认WebSocket连接是否成功建立，以及onmessage事件是否被触发；最后，检查音频文件路径是否正确，以及浏览器是否允许自动播放。
通过引入type字段区分消息类型，系统实现了灵活的扩展性。未来若增加新的提醒类型（如配送员接单提醒、订单已完成提醒等），只需在后端组装对应type的消息，前端增加相应的音频处理逻辑即可，无需改动底层的通信架构。这种基于消息类型的解耦设计，是构建高可用、易维护的实时通知系统的重要实践。