很多跑腿系统把"配送费计算"和"调度派单"拆成两个独立模块。
表面看起来逻辑清晰，实际上却埋下隐患：
- 价格和运力脱节
- 高峰不调价，骑手接不过来
- 运力不足却仍然按原价接单
- 远距离订单大量堆积
如果配送费不和调度系统联动，平台就无法真正做到供需平衡。
真正成熟的架构设计是：
配送费 = 成本预估 + 运力状态 + 实时调度能力 的综合结果
下面我们从架构、数据结构和核心代码实现三个层面讲清楚。
一、整体架构设计思路
跑腿系统核心模块可以抽象为：
- 订单模块
- 配送费计算模块
- 调度模块
- 运力监控模块
关键点在于：
配送费计算必须依赖调度系统提供的实时运力数据。
架构流程如下：
- 用户发起下单请求
- 系统预估距离
- 调度模块评估当前区域运力
- 根据运力情况动态计算配送费
- 返回最终价格给用户确认
而不是先固定算好价格再派单。
二、核心数据结构设计
1. 运力状态表
sql
CREATE TABLE delivery_capacity (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
region_id BIGINT,
online_rider_count INT,
busy_rider_count INT,
waiting_order_count INT,
update_time DATETIME
);这个表用于实时统计区域运力。
2. 配送规则表
sql
CREATE TABLE delivery_fee_rule (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
base_price DECIMAL(10,2),
base_distance DECIMAL(5,2),
per_km_price DECIMAL(10,2),
surge_ratio DECIMAL(5,2) -- 动态加价比例
);三、配送费与调度联动核心逻辑
第一步：评估运力紧张程度
java
public BigDecimal calculateSurgeRatio(DeliveryCapacity capacity) {
int availableRiders = capacity.getOnlineRiderCount()
- capacity.getBusyRiderCount();
if (availableRiders <= 0) {
return new BigDecimal("0.5"); // 加价50%
}
double ratio = (double) capacity.getWaitingOrderCount()
/ availableRiders;
if (ratio > 2) {
return new BigDecimal("0.3");
}
if (ratio > 1) {
return new BigDecimal("0.2");
}
return BigDecimal.ZERO;
}逻辑解释：
- 待派订单多、可用骑手少 → 动态加价
- 运力充足 → 不加价
这就是供需调节。
第二步：计算基础配送费
java
public BigDecimal calculateBaseFee(Order order, DeliveryFeeRule rule) {
BigDecimal fee = rule.getBasePrice();
if (order.getDistance().compareTo(rule.getBaseDistance()) > 0) {
BigDecimal extra = order.getDistance()
.subtract(rule.getBaseDistance());
fee = fee.add(extra.multiply(rule.getPerKmPrice()));
}
return fee;
}第三步：融合调度状态计算最终费用
java
public BigDecimal calculateFinalFee(Order order) {
DeliveryFeeRule rule = ruleRepository.getActiveRule();
DeliveryCapacity capacity = capacityService.getByRegion(order.getRegionId());
BigDecimal baseFee = calculateBaseFee(order, rule);
BigDecimal surgeRatio = calculateSurgeRatio(capacity);
BigDecimal surgeFee = baseFee.multiply(surgeRatio);
return baseFee.add(surgeFee);
}核心思想：
价格 = 基础成本 + 运力溢价
四、调度派单与费用联动
当订单创建完成后，调度系统也必须考虑配送费因素。
例如优先派单给高收益订单：
java
public Rider dispatch(Order order) {
List<Rider> riders = riderRepository.findAvailable(order.getRegionId());
return riders.stream()
.min(Comparator.comparing(r -> distance(r, order)))
.orElse(null);
}同时，可以根据配送费决定优先级：
java
orders.sort((o1, o2) ->
o2.getDeliveryFee().compareTo(o1.getDeliveryFee())
);收益高的订单优先处理，有助于提高履约效率。
五、高并发下防止重复派单
调度联动必须避免重复抢单问题。
使用 Redis 分布式锁：
java
String lockKey = "dispatch:" + order.getId();
Boolean success = redisTemplate.opsForValue()
.setIfAbsent(lockKey, "1", 5, TimeUnit.SECONDS);
if (!success) {
throw new RuntimeException("订单正在派单中");
}六、为什么必须联动？
如果配送费不和调度系统联动，会出现三个严重问题：
第一，价格无法反映实时运力。
第二，高峰期履约效率下降。
第三，远距离订单堆积。
而一旦联动：
- 运力紧张 → 自动提高收益 → 吸引骑手
- 运力充足 → 价格恢复 → 提升转化率
这才是真正健康的调节机制。
七、结语
跑腿小程序的核心不是"算出一个价格"，而是通过价格调节供需关系。
配送费与调度系统联动，本质上是：
用价格机制平衡运力与订单。
如果配送费只是一个固定参数，你的系统只是一个下单工具。
如果配送费能随调度状态动态变化，你才真正做到了平台级架构。
技术的价值，不在于代码多少，而在于是否解决结构问题。
跑腿系统想长期稳定运行，配送费与调度联动，是必做的一步。