上门维修平台小程序软件派单模块拆解：抢单、派单、指派三种模式的实现逻辑
导语
派单模块是上门维修平台软件技术含量最高的模块，也是线上事故最集中的模块：重复分配、订单僵死、超时漏派，三类高频故障全部源自这里。本篇把抢单、系统派单、人工指派三种模式的实现逻辑逐个拆到代码级流程，讲清每种模式的状态机形态、并发控制手段和适用边界，最后给出三模式共存的配置化设计方案。适合负责调度模块的后端工程师和架构师，读完整篇可以直接对照设计派单引擎的模块结构与接口。
一、先立总纲：三种模式共享的调度骨架
三种模式看起来流程迥异，但入口和出口是一致的，先看整体骨架：
无论走哪条分支，调度模块都必须保证三件事：
- 模式可路由：工单进入"待派单"状态后，按服务类目/城市/时段的配置路由到抢单池、系统派单引擎或人工调度台；
- 轨迹全落库：模式选择依据、候选师傅列表、每次推送与响应记录全部持久化——这是纠纷仲裁和算法迭代的数据底座；
- 出口收敛：无论哪条分支，最终都收敛到"已接单"状态，且全局保证一单只被一位师傅锁定。
下面逐个模式拆解。
二、抢单模式：并发竞争与原子锁
抢单模式的本质是"把分配权交给师傅"，实现重点全在并发控制上。
2.1 抢单池的数据结构
合格工单（通过审核、支付完成、服务时间有效）发布到抢单池。抢单池用 Redis 实现，核心结构有两个：
- 订单索引：
zset按发布时间排序，师傅端大厅拉取列表用zrangebyscore分页取； - 订单详情缓存：
hash存储工单摘要（类目、地址网格、预约时段、报价区间），命中缓存避免回源 MySQL。
师傅端大厅的刷新策略建议"推拉结合"：有新工单时经厂商推送通道发一条轻量通知（只含"有新单"信号），师傅端收到后主动拉取列表——纯轮询浪费电和带宽，纯推送则到达率不可控。
2.2 抢单的原子性：一条命令解决 90% 的问题
师傅点击抢单，服务端执行的核心操作是一条 Redis 原子命令：
SET grab:order:{orderId} {workerId} NX EX 30
NX保证只有第一个请求能成功——这就是"一单只被一人抢到"的全部秘密；EX 30设置锁 TTL，防止师傅端崩溃或流程中断导致订单永久锁死；- 成功后进入业务处理：更新工单状态为"已接单"、落库接单记录、推送用户端通知；业务处理期间用看门狗机制续期，防止业务耗时超过 30 秒锁先过期；
- 失败的请求立即返回"已被抢走"，不允许排队等待——抢单场景的失败方，体验要求是"快"，不是"等"。
进阶方案是 Redisson 的分布式锁（tryLock + WatchDog 自动续期），它把 TTL 管理和续期自动化了，代价是多一层客户端依赖。公开的技术实践数据显示，分布式锁方案可以把高并发抢单场景的成功率从无锁方案的 61% 提升到 99.9% 以上，平均响应从秒级降到几十毫秒——这笔投入在抢单模式下完全值得。
2.3 抢单模式的两个衍生问题
状态不一致：极端情况下（Redis 主从切换丢锁），可能出现两个师傅都认为自己抢到了。兜底方案是数据库层加条件更新：UPDATE work_order SET worker_id=? WHERE id=? AND worker_id IS NULL，affected rows 为 0 说明已被占用，回滚 Redis 锁并提示失败。Redis 锁管性能，数据库条件更新保最终一致，两层缺一不可。
恶意抢单：批量注册的账号刷单占坑再转卖，需要接入设备指纹、同设备多账号识别、抢单频率限制（令牌桶按师傅维度限流）。
三、系统派单模式：过滤、评分、推送、重派
系统派单把分配权收归平台，引擎是一条四段流水线。
3.1 硬过滤阶段
用规则过滤掉不合格候选：地理半径（Redis Geo GEOSEARCH 半径内）、技能标签匹配、排班冲突（预约时段与已有工单重叠）、接单意愿（师傅主动暂停接单）、合规状态（资质过期、处罚冻结中）。硬过滤的原则是"宁缺勿滥"——过滤后候选为空好过派给错误的人。
3.2 评分排序阶段
对候选集做多因子评分，典型公式：
score = w1 × 距离分 + w2 × 技能匹配分 + w3 × (1 - 当前负载/最大负载) + w4 × 历史评分分 - 惩罚项
工程要点是权重配置化：距离权重在用户敏感场景调高、负载权重在师傅公平性要求高的场景调高，运营应能在后台调整并看到调整前后的仿真对比。惩罚项承接处罚体系：近期投诉、超时记录按衰减函数计入。
3.3 推送与响应窗口
评分最高的师傅进入推送。这一步的并发模型参考即时配送行业的成熟实践：对候选师傅加分布式锁（SET dispatch:worker:{wid} {orderId} NX EX 60），锁 TTL 对齐响应窗口（如 60 秒）。锁的意义是防止该师傅同时被派两单——一个师傅手里已经有一单在考虑时，引擎跳过他直接试下一位，不浪费响应窗口。
师傅响应分三种：接受（锁定工单，流程结束）、拒绝（记录拒单原因——结构化字段而非自由文本，便于统计"某片区/某类目拒单率异常"）、超时（释放师傅锁，顺延下一位）。
3.4 重派与兜底
候选列表全部试完仍无人接单，进入重派策略：半径逐级扩大（3km → 5km → 8km，级数与步长可配）、加价激励（可选，需财务配置）、最终转人工调度台。重派全程写入派发轨迹，避免"同一单反复推给同一个拒单师傅"这类低级错误——这是真实系统里出过的事故。
四、人工指派模式：兜底的艺术
人工指派是自动化失效时的最后防线，设计目标不是效率而是信息完备：
- 调度台界面呈现工单全量上下文：地址、历史服务记录、故障描述、用户等级、投诉标记；
- 候选师傅列表除评分外，显示在途单数、当日完成单数、最近拒单原因；
- 指派动作同样走"推送 + 响应窗口 + 锁"的流程，只是决策由人做出；
- 指派记录入审计日志——谁派的、依据什么派的，纠纷追溯时必须有答案。
人工指派的比例本身是个运营指标：占比持续上升说明自动派单的过滤条件或评分权重出了问题，应触发算法复盘而不是继续堆人力。
五、三模式共存的配置化设计
真实的平台不会只跑一种模式。推荐的路由配置维度：
| 维度 | 示例配置 |
|---|---|
| 按类目 | 家电清洗走抢单（供给充裕），防水补漏走系统派单（技能稀缺） |
| 按时段 | 深夜订单直接转人工（自动派单失败率高，节省重派等待） |
| 按城市 | 供给侧成熟城市全自动化，新城市冷启动阶段人工指派为主 |
| 按订单属性 | 高价值单/投诉关联单强制人工复核后才派发 |
实现上用一张路由规则表（类目 × 城市 × 时段 → 模式），规则变更走配置中心实时生效。三种模式共用同一套"响应窗口 + 锁 + 状态机"底层原语，差异只在决策者（师傅/算法/人）——这样三种模式不会演化成三套代码。
实操要点
技术总结
三种派单模式的实现可以浓缩为一组共享原语（状态机、响应窗口、分布式锁）加三个决策者：抢单模式把决策交给师傅，核心是原子锁与限流；系统派单交给算法，核心是过滤—评分—推送—重派四段流水线与权重配置化；人工指派交给人，核心是信息完备与审计。工程上最值钱的三条经验：Redis 锁 + 数据库条件更新双层防线、拒单原因结构化、派发轨迹全量落库。
派单的第一输入是"附近有哪些师傅"，这依赖位置数据的质量与检索效率——下一篇拆解
浙公网安备 33010602011771号