当前位置: 首页 > news >正文

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

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

系统派单的目的是什么?

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

在本篇文章中,我们将系统性介绍家政平台派单调度模块的架构设计、关键技术选型与实现细节,尤其围绕距离匹配、失败重试、派单策略扩展等核心需求展开,结合实际项目中使用的技术框架(如 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)

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

相关文章:

  • Unity-Shader详解-其四
  • BUUCTF——Mark loves cat
  • CloudCompare 中 ccDrawableObject
  • 健康养生:从微小改变开始
  • 2025系统架构师---论软件可靠性设计范文
  • yolo 用roboflow标注的数据集本地训练 kaggle训练 comet使用 训练笔记5
  • 从零开始学Python:开启编程新世界的大门
  • C++ 适配器模式详解
  • uniapp 云开发全集 云数据库
  • 11.施工监测
  • 【项目】基于ArkTS的网吧会员应用开发(1)
  • NHANES指标推荐:ZJU index
  • 作者新游戏1.1
  • 什么是外联模板(extern template)?
  • 解锁现代健康密码:科学养生新主张
  • Qt中的UIC
  • 【机器学习-线性回归-5】多元线性回归:概念、原理与实现详解
  • 数据库的二级索引
  • 2022年全国青少年信息素养大赛 Python编程挑战赛 小学/初中组 初赛真题答案详细解析
  • 直方图比较
  • 山大齐鲁医院回应论文现“男性确诊子宫肌瘤”:给予该护士记过处分、降级处理
  • 海港负国安主场两连败,五强争冠卫冕冠军开始掉队
  • 《水饺皇后》领跑五一档票房,《哪吒2》上座率仍居第一
  • 解放日报:人形机器人新赛道正积蓄澎湃动能
  • 国铁集团去年收入12830亿元增3%,全年铁路运输利润总额创新高
  • 浪尖计划再出发:万亿之城2030课题组赴九城调研万亿产业