家政平台派单系统设计与实现详解
在抢单业务中,用户下单成功由服务人员或机构进行抢单,抢单成功服务人员上门服务,除了抢单业务系统还设计了派单业务,由系统根据用户订单的特点自动派给合适的服务人员。
系统派单的目的是什么?
根据订单的特点及服务人员的特点进行撮合,提高交易成功率。
在本篇文章中,我们将系统性介绍家政平台派单调度模块的架构设计、关键技术选型与实现细节,尤其围绕距离匹配、失败重试、派单策略扩展等核心需求展开,结合实际项目中使用的技术框架(如 Redis、Elasticsearch、Canal、MQ、策略模式、责任链模式、线程池、XXL-Job)一一剖析其技术落地方案。
一、背景与需求分析
家政服务订单匹配不仅是“找人”这么简单,而是综合考虑服务技能、时间、地理距离、订单重复尝试等多个因素,需要一个灵活、可扩展且高性能的派单系统。
关键需求包括:
-  根据地理位置、服务时间和技能,快速筛选合适的服务人员。 
-  派单失败后需定期重试,提升订单履约率。 
-  支持多种派单策略,适应不同城市运营模式。 
-  保证服务公平性,机器与人工同时具备抢单机会。 
二、系统整体架构设计
为了满足上述复杂需求,我们设计了如下整体架构:
-  ✅ 数据同步层:MySQL → Elasticsearch(服务人员)、MySQL → Redis(派单池) 
-  ✅ 调度执行层:XXL-Job + Redis ZSet 实现定时调度派单任务 
-  ✅ 业务匹配层:策略模式 + 责任链模式筛选最优服务人员 
-  ✅ 执行派单层:平台调用抢单接口完成“机器抢单” 
三、核心技术实现
1. 服务人员同步到 Elasticsearch(支持距离搜索)
为了实现“按地理位置搜索服务人员”的功能,使用 Elasticsearch 进行地理位置范围匹配。服务人员信息包含:
-  接单范围 
-  服务技能列表 
-  可服务时间 
-  当前状态等 
这些数据通过 Canal + MQ 实时同步:
-  Canal 监听服务人员/机构表的 binlog 
-  通过 MQ 推送更新事件,后台服务更新 Elasticsearch 索引 
2. Redis 构建派单池(失败重试)
Redis 中使用 ZSet 维护派单池:
-  Key: ORDERS:DISPATCH:LIST
-  Member:订单 ID 
-  Score:加入派单池时间戳(单位:秒) 
调度逻辑:
-  每 3 分钟扫描一次派单池,取出 score <= 当前时间的订单尝试派单
-  如果派单失败,再将 score += 180,重新进入派单池等待下一轮尝试
这一方式确保失败订单能够被周期性重试,提升派单成功率。
3. 派单策略模式 + 责任链模式
-  策略模式:支持多种派单策略(按距离优先、按评分优先、轮询等),可扩展性强 
-  责任链模式:每个策略内部按“规则链”依次过滤服务人员,如: -  地理距离过滤 
-  服务技能匹配 
-  可服务时间校验 
-  服务质量排序 
 
-  
代码结构清晰,便于新增规则和策略。
4. 平台与人工共同抢单
最终筛选出最合适的服务人员后,平台将发起一次“机器抢单”请求(模拟服务人员抢单),调用抢单接口:
OrderSeizeReqDTO orderSeizeReqDTO = new OrderSeizeReqDTO();
orderSeizeReqDTO.setSeizeId(id);
orderSeizeReqDTO.setServeProviderId(serveProvider.getId());
orderSeizeReqDTO.setServeProviderType(serveProvider.getServeProviderType());
ordersSeizeApi.machineSeize(orderSeizeReqDTO);这样可实现服务人员与平台共同参与抢单,体现公平机制。
5. 定时调度使用 XXL-Job
核心定时任务如下:每次从 Redis ZSet 扫描待派订单,触发业务逻辑:
@XxlJob("dispatch")
public void dispatchDistributeJob() {Set<Long> ordersDispatchIds = redisTemplate.opsForZSet().rangeByScore(DISPATCH_LIST, 0, DateUtils.getCurrentTime(), 0, 100);if (CollUtils.isEmpty(ordersDispatchIds)) return;for (Long id : ordersDispatchIds) {dispatch(id);}
}每个订单派单任务通过线程池异步执行,保证并发性能。
四、自定义线程池保障并发性能
派单任务通过线程池异步处理,防止主线程阻塞。线程池配置如下:
@Bean("dispatchExecutor")
public Executor dispatchExecutor(ExecutorProperties executorProperties) {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();executor.setCorePoolSize(16);executor.setMaxPoolSize(32);executor.setQueueCapacity(500);executor.setThreadNamePrefix("dispatch-");executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());executor.initialize();return executor;
}🚀 常见线程池参数说明:
| 参数 | 说明 | 
|---|---|
| corePoolSize | 核心线程数(常驻线程数) | 
| maxPoolSize | 最大线程数 | 
| queueCapacity | 等待队列长度 | 
| keepAliveTime | 空闲线程存活时间(默认60s) | 
| RejectedExecutionHandler | 拒绝策略(如线程数已满时) | 
✅ 为什么要自定义线程池?
-  控制线程数量,防止资源耗尽 
-  设置线程命名,便于排查问题 
-  可结合服务器性能灵活配置 
⚙️ 线程池参数如何配置?
以 8 核 CPU 的服务器为例(IO密集型任务):
-  corePoolSize = 16
-  maxPoolSize = 32
-  queueCapacity = 500
-  拒绝策略: CallerRunsPolicy,保证任务不丢失
建议通过配置中心动态调整线程池参数,结合监控系统(如 Prometheus + Micrometer)观察线程活跃情况、拒绝任务数,及时优化。
五、总结
本系统通过 Redis + Elasticsearch + MQ + 多线程调度 的组合,实现了一个高性能、可扩展、支持多种派单策略的家政平台派单系统。其亮点包括:
-  💡 数据结构设计合理(ZSet 支持定时重试) 
-  💡 模式设计灵活(策略+责任链) 
-  💡 性能保障(异步线程池 + XXL-Job) 
-  💡 技术选型成熟(MQ、Canal、ES) 
适合中大型服务平台参考和借鉴。
