昭通市公安局网站是谁做的百度扫一扫识别图片

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

系统派单的目的是什么？

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

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

• 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）

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