家政平台派单系统设计与实现详解

在抢单业务中,用户下单成功由服务人员或机构进行抢单,抢单成功服务人员上门服务,除了抢单业务系统还设计了派单业务,由系统根据用户订单的特点自动派给合适的服务人员。

系统派单的目的是什么?

根据订单的特点及服务人员的特点进行撮合,提高交易成功率。

在本篇文章中,我们将系统性介绍家政平台派单调度模块的架构设计、关键技术选型与实现细节,尤其围绕距离匹配、失败重试、派单策略扩展等核心需求展开,结合实际项目中使用的技术框架(如 Redis、Elasticsearch、Canal、MQ、策略模式、责任链模式、线程池、XXL-Job)一一剖析其技术落地方案。

一、背景与需求分析

家政服务订单匹配不仅是“找人”这么简单,而是综合考虑服务技能、时间、地理距离、订单重复尝试等多个因素,需要一个灵活、可扩展且高性能的派单系统。

关键需求包括:

  1. 根据地理位置、服务时间和技能,快速筛选合适的服务人员。

  2. 派单失败后需定期重试,提升订单履约率。

  3. 支持多种派单策略,适应不同城市运营模式。

  4. 保证服务公平性,机器与人工同时具备抢单机会。

二、系统整体架构设计

为了满足上述复杂需求,我们设计了如下整体架构:

  • 数据同步层:MySQL → Elasticsearch(服务人员)、MySQL → Redis(派单池)

  • 调度执行层:XXL-Job + Redis ZSet 实现定时调度派单任务

  • 业务匹配层:策略模式 + 责任链模式筛选最优服务人员

  • 执行派单层:平台调用抢单接口完成“机器抢单”

三、核心技术实现

1. 服务人员同步到 Elasticsearch(支持距离搜索)

为了实现“按地理位置搜索服务人员”的功能,使用 Elasticsearch 进行地理位置范围匹配。服务人员信息包含:

  • 接单范围

  • 服务技能列表

  • 可服务时间

  • 当前状态等

这些数据通过 Canal + MQ 实时同步:

  • Canal 监听服务人员/机构表的 binlog

  • 通过 MQ 推送更新事件,后台服务更新 Elasticsearch 索引

2. Redis 构建派单池(失败重试)

Redis 中使用 ZSet 维护派单池:

  • KeyORDERS: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)

适合中大型服务平台参考和借鉴。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值