鲁班到家做的是大家居后市场服务：家具、家电、卫浴、灯具的安装、维修、清洗。需求方一边是品牌商与经销商（要的是全国售后网络），另一边是家庭用户（要的是同城上门）。
这类业务的难点在履约而不是下单：订单要落到具体城市的师傅身上，师傅分散在全国、能力参差、档期不一；一单从下单到完成要经过派单、接单、上门、完成、核销五六个节点，任何一环卡住就是一次客诉。
而且企业客户按项目批量下单，一个门店几十台空调要分批发装，改约、取消、二次上门都是常态。平台必须在"订单状态"和"师傅履约"两条线上同时保证一致。
1）下单：企业客户批量下单、家庭用户即时下单，按品类与城市计算价格与服务时效；
2）派单：按服务区域、品类技能、师傅分层与档期做派单，支持指派与抢单两种模式；
3）接单与履约：接单、出发、上门、完成四个节点上报，关键节点要求拍照与定位凭证；
4）超时与改约：超时未接自动流转到下一轮派单，改约与取消走审批与责任判定；
5）核销与结算：服务完成后按节点核销，生成师傅结算单与企业账单；
6）师傅分层：按服务行为数据做接单权益升降级，高分师傅优先派单；
7）售后工单：安装质量问题转售后工单，支持二次上门与赔付；
8）运营后台：订单检索、履约看板、异常订单预警。
我负责下单接单主链路，日均约 3 万单。
技术栈：Java / Spring Cloud，MySQL 存订单主表与状态流水，Redis 做档期锁与幂等令牌，RocketMQ 做异步解耦与补偿。
关键实现：
① 状态机收口：订单所有状态跳变走同一状态机，每次跳变校验前置状态，杜绝"已取消的订单又被支付成功""已完成的单又被改约"这类脏数据。
② 支付回调幂等：以商户订单号 + 支付流水号做唯一键，重复回调直接返回成功不重复改单；乱序回调按订单版本号丢弃旧事件。
③ 超时未接自动流转：延迟消息投递，到期检查状态，仍在待接单则触发下一轮派单。用延迟消息而不是扫表轮询，避免高峰期把库打满。
④ 档期冲突：师傅同一时间段只能接一单，用 Redis 原子锁占档，下单时先锁档期再落单，避免两单派给同一人。
⑤ 补偿：消费失败进重试队列，指数退避，超阈值落异常表并告警，保证最终一致。
峰值期下单接口 P99 稳定在 200ms 以内，重复下单与支付错账类客诉基本清零。
评论