家政平台派单系统设计与实现详解
在抢单业务中,用户下单成功由服务人员或机构进行抢单,抢单成功服务人员上门服务,除了抢单业务系统还设计了派单业务,由系统根据用户订单的特点自动派给合适的服务人员。
系统派单的目的是什么?
根据订单的特点及服务人员的特点进行撮合,提高交易成功率。
在本篇文章中,我们将系统性介绍家政平台派单调度模块的架构设计、关键技术选型与实现细节,尤其围绕距离匹配、失败重试、派单策略扩展等核心需求展开,结合实际项目中使用的技术框架(如 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)
适合中大型服务平台参考和借鉴。