体育外卖系统开发实战：从需求拆解到上门派单的架构设计

体育外卖系统开发实战从需求拆解到上门派单的架构设计「体育外卖」这个词听起来像是把运动装进餐盒但在工程视角下它指的是一类很明确的系统用户在小程序或 App 上下单选择运动项目、时间、地点平台把订单派给附近符合条件的教练或陪练由服务者上门或到指定场地完成履约。它复用了外卖系统核心的三件事——LBS 匹配、订单状态流转、即时消息触达同时又叠加了体育行业特有的排期、加钟、多端协同等需求。本文不谈商业模式只从技术实现角度把「体育外卖」这类系统拆开讲一遍包括架构选型、核心链路、关键代码和常见坑点适合正在做预约上门类项目的开发者参考。一、业务模型与技术边界在动手写代码前需要先把「体育外卖」的业务对象定义清楚。一个典型的实体关系大致是这样服务者教练 / 陪练 / 助教有资质信息、擅长项目、可服务时间段、服务半径、接单开关。服务项目羽毛球陪练、网球私教、台球助教、上门体适能等每个项目有默认时长、人数上限、需要携带的器材。场地一部分是上门用户指定地址一部分是到店合作场馆的固定场地还有自带场地的混合模式。订单包含预约时间、服务地点、项目快照、费用计算明细、履约状态。和普通外卖的区别在于时间维度不是「立即」而是「预约」。外卖是「现在送」体育外卖是「今晚七点到九点在我家楼下的球场」。这意味着系统必须处理三类冲突教练同一时间段不能被两个订单占用场地同一时间段不能被重复预订用户改期、取消会引发连锁的资源释放与重新派单。因此排期与锁时段是整个系统的技术核心比派单算法本身更重要。二、系统架构与端侧划分这类系统通常是四端结构建议在项目初期就按端拆分仓库和服务边界避免后期互相拖累端使用方主要职责用户端学员选项目、选时段、下单、支付、评价服务者端教练 / 陪练接单、排班维护、上下线、加钟确认管理后台运营项目配置、订单干预、退款审核、数据看板骑手 / 调度端可选平台调度异常订单改派、超时提醒技术选型上一套比较稳妥的组合是后端 Spring Boot MyBatis Plus/MyBatis数据库 MySQL缓存与分布式锁用 Redis位置检索用 Redis GEO 或 PostGIS用户端用 UniAppVue 语法一次编译多端管理后台用 Vue Element UI。消息通道按端区分小程序走订阅消息App 走厂商推送通道服务者端额外加短信或提醒作为兜底。三、核心链路从下单到上门派单3.1 时段锁定与防超卖预约类系统常见的线上事故就是「一个教练被卖出两个时段」。推荐用「数据库索引 Redis 分布式锁」双保险CREATETABLEcoach_schedule(idBIGINTPRIMARYKEYAUTO_INCREMENT,coach_idBIGINTNOTNULL,slot_startDATETIMENOTNULL,slot_endDATETIMENOTNULL,order_idBIGINTDEFAULTNULL,statusTINYINTNOTNULLDEFAULT0COMMENT0空闲 1锁定 2已占用,UNIQUEKEYuk_coach_slot(coach_id,slot_start));uk_coach_slot这一条索引是后一道防线。哪怕缓存击穿、锁失效数据库也会拦下重复写入业务层捕获DuplicateKeyException后返回「该时段已被预约」即可。如果服务时长不固定比如用户选 90 分钟单纯的索引就不够了需要改成区间重叠检测// 判断是否存在时间区间重叠booleanconflictscheduleMapper.existsOverlap(coachId,start,end);// 对应 SQL 片段// SELECT COUNT(1) FROM coach_schedule// WHERE coach_id #{coachId}// AND status IN (1, 2)// AND slot_start #{end}// AND slot_end #{start}slot_start end AND slot_end start这个写法比BETWEEN更可靠能正确处理跨时段、跨天的区间。3.2 附近服务者检索上门类业务必须先解决「谁离得近」。用 Redis GEO 存服务者的常驻点用GEOSEARCH按半径召回再叠加业务过滤// 1. 从 Redis 召回 5km 内的服务者GeoResultsRedisGeoCommands.GeoLocationStringresultsredisTemplate.opsForGeo().search(coach:geo,GeoReference.fromCoordinate(lng,lat),newDistance(5,Metrics.KILOMETERS),GeoSearchCommandArgs.newGeoSearchArgs().includeDistance().limit(50));// 2. 过滤项目匹配 时段空闲 接单开关开启 资质有效ListLongcandidateIdsresults.getContent().stream().map(r-Long.valueOf(r.getContent().getName())).filter(id-coachCache.isAvailable(id,projectId,start,end)).collect(Collectors.toList());// 3. 计算实际距离含上门路线用直线距离做初筛即可注意 Redis GEO 返回的是直线距离山区、跨江、单行道较多的城市会有偏差所以终展示给用户或用于派单评分时建议再调一次路径规划接口拿真实通行距离和预计耗时。直线距离用于初筛真实距离用于决策这样能明显降低外部接口调用量。3.3 派单评分与派单策略候选集有了接下来是排序。一个可解释、易调参的线性加权评分模型就足够了不必一上来就上复杂模型doublescorew1*distanceScore// 距离越近分越高w2*ratingScore// 历史评分w3*orderCountScore// 近期接单量用于均衡分配w4*responseScore;// 历史接单响应速度权重建议做成配置项存库运营侧可以按城市调整。派单模式分两种抢单模式把订单推给 Top N 候选人先到先得。实现简单但冷启动阶段容易出现「大范围无人接单」。指派模式系统直接指定超时未响应自动改派下一位。履约确定性高但要处理服务者的拒绝理由和疲劳度。实践中常见的是混合模式高峰期用指派保履约平峰期用抢单提升利用率。无论用哪种都要有一个「未接单超时后逐级扩大半径」的兜底任务用延迟队列RocketMQ 延时消息或 Redis ZSet实现即可。四、订单状态机与消息触达体育外卖的订单生命周期比外卖长得多从下单到履约完成可能跨越数天。强烈建议把状态流转收敛到一个显式的状态机里而不是散落在各个 Service 的if-else中待支付 → 待接单 → 待服务 → 服务中 → 待确认 → 已完成 ↓ ↓ ↓ ↓ 已取消 已取消 已取消 争议中每一跳都要回答三个问题谁能触发、触发后释放什么资源、通知谁。比如「待接单 → 已取消」时必须释放排期锁、关闭待派单任务、给服务者发送取消通知「服务中 → 待确认」时需要延迟发起确认任务用户超过约定时间未确认则自动完成。消息触达按端的特性分开处理小程序订阅消息有一次性限制要在用户下单、支付等关键动作时提前收集订阅授权App走厂商推送注意 Android 各家通道的后台保活策略差异服务者端接单提醒属于强时效场景推送 短信双通道更稳服务号模板消息可作为补充。建议把「发送通知」抽象成一个事件由订单状态变更事件驱动用TransactionalEventListener(phase AFTER_COMMIT)在事务提交后再发避免事务回滚但消息已发出的不一致问题。五、落地过程中的几个坑时区与夏令时。预约时间必须统一存 UTC 再按用户时区展示涉及跨时区业务时LocalDateTime会带来灾难改用Instant或带时区的ZonedDateTime。订单快照。项目名称、时长、教练信息都要在订单里存快照。运营改一次项目配置历史订单不能跟着变。加钟与超时。服务中途加钟是高频操作需要单独的「加钟单」并再次校验后续时段是否空闲不能直接改原订单时长。取消与退款时机。取消规则要和排期释放解耦取消成功不等于排期立刻可售中间可能还有争议处理流程。冷启动。新城市服务者少的时候先缩小可下单半径保证履约质量比全城开放更有效。体育外卖本质上是一个资源排期 位置匹配 状态流转的组合题。把这三件事的技术底座打牢上层无论加多少项目类型都不会伤筋动骨。FAQQ1体育外卖系统和普通外卖系统能复用同一套代码吗部分可以。订单状态机、消息通知、支付链路基本可复用但排期锁定、时段冲突检测、加钟逻辑是预约类业务独有的硬套外卖模型会导致大量补丁。建议订单域独立建模。Q2附近服务者检索用 MySQL 还是 Redis GEO数据量小几千个服务者时 MySQL 的经纬度范围查询配合索引就够用超过一定规模或需要频繁按半径召回用 Redis GEO 或 PostGIS 性能更稳定。两者也可以组合MySQL 存全量Redis 存活跃服务者的位置。Q3如何避免教练被重复预约核心是数据库索引兜底 应用层分布式锁 区间重叠检测三重保障。索引是后防线锁只是为了减少冲突带来的异常。Q4用户改期怎么实现把改期拆成「取消原订单排期 创建新排期」两个原子步骤放在同一个事务里任何一步失败整体回滚避免出现排期悬空。Q5上门履约如何保证安全技术上可以做虚拟号码中转、服务过程录音授权、紧急联系人一键报警、异常订单风控标记等。这些能力应在订单创建时就绑定而不是事后补救。