首页
手游
资讯
专题
首页 > 教程攻略 > ai教程 >从0到1搭建外卖跑腿配送系统全流程解析

从0到1搭建外卖跑腿配送系统全流程解析

来源：互联网 时间：2026-07-05 07:52:13

外卖跑腿配送系统，说到底，就是一个围绕“多角色、实时调度、地理位置驱动”构建起来的同城即时履约体系。它一头连着用户，一头连着商家，中间跑着骑手，背后还有管理后台在统揽全局。

今天咱们就不绕弯子，直接从业务流程到技术架构，再到那些最核心的代码片段，把一套真正可落地的系统设计拆开揉碎了来讲。

外卖跑腿配送系统外卖跑腿配送系统

一个标准的外卖跑腿系统，大多采用分层或微服务/模块化的架构。先从业务端看起：用户端负责下单、支付、追踪订单；商家端处理接单、出餐和订单管理；骑手端则围绕抢单、配送和签收展开；而管理后台，负责订单调度、风控和数据分析。

技术层面，前端多用Vue、React，或者直接上小程序和App；后端则偏向Ja va Spring Boot、Node.js或Go；数据库结合MySQL和Redis；地图服务绕不开高德或Google Maps；消息系统靠WebSocket或MQTT；定位则依赖GPS加LBS。

核心业务流程

整个系统的主链路其实很清晰：用户下单，商家接单，系统开始派单（或者让骑手抢单），骑手接单后去取餐，然后配送，最后完成订单，结算评价。这里面最关键的节点，就在第三步——派单逻辑。

核心模块拆解

1. 订单模块

订单是系统的灵魂数据。一个简化版的订单表设计，大致长这样：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT,
  merchant_id BIGINT,
  rider_id BIGINT,
  status VARCHAR(20),
  total_amount DECIMAL(10,2),
  create_time DATETIME,
  update_time DATETIME
);

2. 下单接口（后端示例）

拿Node.js举个例子，下单接口的核心逻辑无非三步：先算出总金额，然后创建订单，最后把订单ID扔进Redis队列，等待派单系统处理。

app.post("/order/create", async (req, res) => {
  const { userId, merchantId, items } = req.body;

  // 1. 计算金额
  const total = items.reduce((sum, item) => {
    return sum + item.price * item.count;
  }, 0);

  // 2. 创建订单
  const order = await db.orders.create({
    user_id: userId,
    merchant_id: merchantId,
    total_amount: total,
    status: "PENDING"
  });

  // 3. 写入Redis用于派单
  await redis.lpush("order_queue", order.id);

  res.json({ success: true, orderId: order.id });
});

3. 派单核心逻辑（重点）

这才是外卖系统“智能化”的真实体现。怎么才能把订单匹配给最近的骑手？思路很直接：先获取订单位置，然后通过LBS查找附近的骑手，再计算距离，最后把订单分给最近的那位。

具体实现上，可以借助Redis的GEO功能来管理骑手位置：

// 骑手上线，存储位置
await redis.geoadd("riders_location", longitude, latitude, riderId);

查询附近骑手：

const riders = await redis.georadius(
  "riders_location", 
  orderLng, 
  orderLat, 
  3,      // 3公里范围
  "km", 
  "WITHDIST", 
  "COUNT", 
  5
);

完整的派单逻辑可以这样封装：

async function dispatchOrder(orderId, orderLng, orderLat) {
  const riders = await redis.georadius(
    "riders_location", 
    orderLng, 
    orderLat, 
    5, 
    "km", 
    "WITHDIST"
  );

  if (!riders.length) {
    throw new Error("暂无可用骑手");
  }

  // 按距离排序
  riders.sort((a, b) => a[1] - b[1]);
  const selectedRider = riders[0][0];

  // 更新订单
  await db.orders.update({
    where: { id: orderId },
    data: { rider_id: selectedRider, status: "DISPATCHED" }
  });

  // 通知骑手（WebSocket/MQTT）
  notifyRider(selectedRider, orderId);

  return selectedRider;
}

4. 实时订单推送（WebSocket）

骑手必须在秒级收到订单通知，这得靠WebSocket来实现：

const WebSocket = require("ws");
const wss = new WebSocket.Server({ port: 8080 });

wss.on("connection", (ws) => {
  ws.on("message", (msg) => {
    const data = JSON.parse(msg);
    if (data.type === "rider_login") {
      ws.riderId = data.riderId;
    }
  });
});

// 推送订单
function notifyRider(riderId, orderId) {
  wss.clients.forEach(client => {
    if (client.riderId === riderId) {
      client.send(JSON.stringify({ type: "NEW_ORDER", orderId }));
    }
  });
}

5. 骑手接单逻辑

接单时得做好状态判断，防止多人同时抢一张单：

app.post("/rider/accept", async (req, res) => {
  const { riderId, orderId } = req.body;
  const order = await db.orders.findById(orderId);

  if (order.status !== "DISPATCHED") {
    return res.json({ success: false, msg: "订单已被接单" });
  }

  await db.orders.update({
    where: { id: orderId },
    data: { status: "ACCEPTED", rider_id: riderId }
  });

  res.json({ success: true });
});

6. 定位更新（骑手端）

骑手的位置需要持续上报，每5秒一次是比较常见的节奏：

setInterval(() => {
  na vigator.geolocation.getCurrentPosition(async (pos) => {
    await fetch("/rider/location/update", {
      method: "POST",
      body: JSON.stringify({
        riderId,
        lng: pos.coords.longitude,
        lat: pos.coords.latitude
      })
    });
  });
}, 5000);

后端接收更新后，写入Redis：

app.post("/rider/location/update", async (req, res) => {
  const { riderId, lng, lat } = req.body;
  await redis.geoadd("riders_location", lng, lat, riderId);
  res.json({ success: true });
});

关键技术难点

实战中，有四个坑是绕不开的。

第一是高并发订单处理。解决方案很成熟：用Redis队列削峰，配合MQ异步派单，必要时分库分表。

第二是实时性。WebSocket已经替代了HTTP轮询，而MQTT在移动端连接优化上表现更佳。

第三是距离计算。Redis GEO是首选，Ha versine公式可以作为备选方案。

第四是防止抢单冲突。分布式锁是标配，用Redis的SETNX就能干净利落地解决：

const lock = await redis.set("order_lock_" + orderId, riderId, "NX", "EX", 10);
if (!lock) {
  return "订单已被抢";
}

系统升级方向

如果目标是一套商业级别的系统，那下面这几项几乎是刚需：

  • 智能派单，引入AI算法，综合距离、负载和骑手评分；
  • 动态调度，支持订单合并配送，提升效率；
  • 路径规划优化，比如用A*或Dijkstra算法；
  • 风控系统，专门用来检测异常骑手行为；
  • 大数据分析，做热区预测，提前调度运力。

外卖跑腿配送系统外卖跑腿配送系统

总结

说到根儿上，外卖跑腿配送系统的核心并不在于“下单”这个动作。真正的技术难点集中在三块：派单算法、实时通信、高并发处理。这三块能打得扎实，系统才真正具备了商用的底气。

相关阅读

相关下载