跑腿小程序配送费与调度系统如何联动？架构设计详解

很多跑腿系统把"配送费计算"和"调度派单"拆成两个独立模块。

表面看起来逻辑清晰，实际上却埋下隐患：

价格和运力脱节
高峰不调价，骑手接不过来
运力不足却仍然按原价接单
远距离订单大量堆积

如果配送费不和调度系统联动，平台就无法真正做到供需平衡。

真正成熟的架构设计是：

配送费 = 成本预估 + 运力状态 + 实时调度能力的综合结果

下面我们从架构、数据结构和核心代码实现三个层面讲清楚。

一、整体架构设计思路

跑腿系统核心模块可以抽象为：

订单模块
配送费计算模块
调度模块
运力监控模块

关键点在于：

配送费计算必须依赖调度系统提供的实时运力数据。

架构流程如下：

用户发起下单请求
系统预估距离
调度模块评估当前区域运力
根据运力情况动态计算配送费
返回最终价格给用户确认

而不是先固定算好价格再派单。

二、核心数据结构设计

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("订单正在派单中");
}

六、为什么必须联动？

如果配送费不和调度系统联动，会出现三个严重问题：

第一，价格无法反映实时运力。

第二，高峰期履约效率下降。

第三，远距离订单堆积。

而一旦联动：

运力紧张 → 自动提高收益 → 吸引骑手
运力充足 → 价格恢复 → 提升转化率

这才是真正健康的调节机制。

七、结语

跑腿小程序的核心不是"算出一个价格"，而是通过价格调节供需关系。

配送费与调度系统联动，本质上是：

用价格机制平衡运力与订单。

如果配送费只是一个固定参数，你的系统只是一个下单工具。

如果配送费能随调度状态动态变化，你才真正做到了平台级架构。

技术的价值，不在于代码多少，而在于是否解决结构问题。

跑腿系统想长期稳定运行，配送费与调度联动，是必做的一步。