跑腿小程序后端5.0架构实践：从订单状态机到分布式并发控制

我一直认为，同城跑腿的后端是所有本地生活系统里最典型的一类业务：它要处理标准的交易链路，又要应付定位、距离、配送计价这些地理相关的问题，更躲不开小程序多端并发、支付回调、消息推送这些偏工程的细节。这套系统我从最早的 JSP 版本一路重构到现在，真正敢对外说"结构完整"的，是当前这个 5.0 版本。

这篇文章不是给你贴一段 CRUD 代码就完事，而是把整个跑腿小程序后端从业务建模、技术选型，到订单状态机、抢单并发控制、微信小程序对接、地图计费、线上故障复盘、部署上线这一条线完整串起来。适合这几类读者：准备从零做跑腿类项目的团队；后端转 Java 微服务想找个真实业务练手的人；已经上线了跑腿系统但觉得订单经常"打架"、支付回调不对账、骑手抢单慢的维护者。你不需要先懂小程序开发，后端部分我会按能直接落地的粒度来讲。

1. 业务建模先行：跑腿单生命周期拆得越细，后端写起来越省事

做这个项目我最强烈的感受是：跑腿系统最难的从来不是某个接口怎么写，而是业务状态到底怎么定义。 如果一上来就建表、写 Controller，后面一定会被各种"订单到底处于什么状态"的疑问反复折磨。5.0 这版我第一周没有写一行 CRUD，全部用来梳理角色、动作和状态流转。

1.1 用户端、骑手端、平台端：三个视角的订单诉求完全不同

多数开发者第一次接触跑腿业务，脑子里只有"用户下单、骑手接单"这一条线，真正动手建模时会发现三端看到的根本不是同一个订单。

用户端关心的是：下单方不方便、能不能看到配送进度、骑手有没有绕路、价格是否透明。所以订单接口必须返回标准化的状态描述、骑手位置轨迹、费用明细，而不能只丢一个"进行中"字符串。

骑手端关心的是：附近有什么单、抢单快不快、配送路线是否合理、收件人是否好联系。于是后端需要提供"按距离范围批量拉取可抢订单"的接口，并且抢单动作必须满足高并发下的唯一性。

平台端关心的是：订单是否超时、退款是否异常、骑手有没有刷单、资金流水是否对得上。这就要求后端必须给每一笔订单做完整的操作日志、状态变更记录和资金流水表，任何一个环节出问题都能回溯到具体人、具体时间、具体坐标。

1.2 跑腿订单的完整生命周期：远不止"下单→完成"这么简单

我把跑腿订单的完整生命周期拆成下面这些节点，后面建表、写状态机全靠这张图：

你会注意到 待支付→待接单→配送中 这些主状态之外，其实还隐藏着大量"子状态"，比如"用户已取消但退款处理中"、"骑手已抢单但超时未取货"、"平台客服介入中"。如果把主状态和子状态全部堆在一个字段里，代码会很快失控。5.0 的处理方式是主状态用枚举严格约束，子状态用额外的 sub_status + 事件表记录，这样统计报表时查主状态，事故溯源时查事件表，互不干扰。

1.3 帮送、帮买、帮排队：业务模式不同，建模也必须区分

跑腿看起来是统一业务，实际上至少要区分三类：帮送（把物品从 A 送到 B）、帮买（去指定店铺买指定商品再送来）、帮办（排队、取号、代办事务）。其中帮买订单尤其特别，因为实际支付金额在下单时是不确定的，用户先付一个"预估金额"，骑手垫付后上传小票，多退少补。

所以我在订单主表里加了一个 order_type 字段，并把费用拆成了几类子表。帮送单费用固定，下单即锁价；帮买单有"预估金额"和"实际金额"两套金额，后续用结算单去拉齐差异。这个小设计让 5.0 在处理帮买退款时没出过一笔糊涂账，算是业务建模阶段最值得的一笔投入。

2. 技术选型与工程约束：5.0 架构在性能与维护成本之间的取舍

很多初学者问：做一个跑腿小程序后端，到底用单体还是微服务？我的回答是：如果你是单城市起盘、日单量不到一万，单体架构完全够用；但如果你和我一样要面对多条业务线、独立团队维护不同模块，按领域拆服务更合适。 5.0 不是纯粹为高并发而生的架构，而是兼顾了开发效率和后续扩展性的折中方案。

2.1 为什么这个项目还是选了 Java 微服务栈

有人说跑腿业务用 Node.js 写起来更轻，用 Go 并发性能更好，为什么我还要选 Java？原因主要来自团队现实：Java 生态里做支付、对账、定时任务、分布式事务的可参考组件实在太成熟了。跑腿业务资金链路复杂，微信支付回调、退款、骑手结算、平台抽佣都需要非常严谨的事务和审计能力，这一块 Spring 体系做得最完善。

5.0 的核心技术栈如下：

这套技术栈对云服务器要求不算低，但 5.0 的目标是"能容纳后续多城市复制推广"，模块之间拆干净了，反而比单体后期更省心。

2.2 5.0 的服务拆法与不拆的部分

我的服务拆分粒度是这样的：user-service 管用户端账户；order-service 管订单、派单、抢单；rider-service 管骑手资质、位置、收入；payment-service 管支付、退款、对账；notification-service 管小程序订阅消息和短信通知；gps-service 管坐标处理、路线规划和距离计算。

值得注意的是，我不建议把一个单城市跑腿系统拆成十几个微服务。 5.0 把"订单+派单"放在同一个服务里，而不是继续拆分成订单服务、营销服务、派单服务，原因是抢单场景高频调用订单表，一旦拆开就要引入大量分布式事务，网络抖动时订单状态不一致的概率会急剧上升。微服务拆分的核心原则是"让频繁一起变化的业务留在同一个服务边界内"，不是越细越好。

2.3 一组必须提前定下的工程约定

前后端分离后，接口风格、鉴权方式和异常结构最好在一开始就统一。5.0 的约定如下：

• 接口统一返回 { code, message, data }，code=0 表示成功，其他表示业务异常。
• 登录态使用自定义 token，小程序每次请求在 Authorization 请求头携带。
• 全局异常处理器捕获所有已知异常，避免错误堆栈直接暴露给前端。
• 所有更新操作必须带 version 字段做乐观锁或指定幂等键。

这些约定听起来基础，但少了任何一条，在多端联调阶段都会变成灾难。尤其是异常结构不一致的问题，小程序端每接一个接口就要写一层奇怪的错误解析逻辑，非常影响体验。

3. 订单核心模块落地：状态机、并发抢单与超时补偿的 Java 实现

进入编码阶段后，第一个要攻克的就是订单状态机。这不是一个可有可无的优化，而是整个订单系统的"宪法"。5.0 把状态流转逻辑收敛到一个类里，之后写任何关于订单的接口，都必须先问状态机是否允许这次流转。

3.1 状态机设计：用枚举把非法流转拦在源头

我先定义订单的主状态枚举：

java复制public enum OrderStatus {
    PENDING_PAY(0, "待支付"),
    PENDING_GRAB(1, "待接单"),
    GRABBED(2, "已接单，待取货"),
    DELIVERING(3, "配送中"),
    COMPLETED(4, "已完成"),
    CANCELED(5, "已取消"),
    REFUNDING(6, "退款中");

    public final int code;
    public final String desc;

    OrderStatus(int code, String desc) {
        this.code = code;
        this.desc = desc;
    }
}

状态机的核心是一个"允许流转的映射表"，任何状态变更不能直接调用 setStatus，必须经过统一入口：

java复制public class OrderStateMachine {

    private static final Map<OrderStatus, Set<OrderStatus>> ALLOWED_TRANSITIONS = new EnumMap<>(OrderStatus.class);

    static {
        // 待支付可以取消或去支付
        ALLOWED_TRANSITIONS.put(OrderStatus.PENDING_PAY,
                Set.of(OrderStatus.CANCELED, OrderStatus.PENDING_GRAB));
        // 待接单只能被骑手抢到或用户取消
        ALLOWED_TRANSITIONS.put(OrderStatus.PENDING_GRAB,
                Set.of(OrderStatus.GRABBED, OrderStatus.CANCELED));
        // 已接单可以进入配送中，骑手或用户均可发起取消（走仲裁流程）
        ALLOWED_TRANSITIONS.put(OrderStatus.GRABBED,
                Set.of(OrderStatus.DELIVERING, OrderStatus.CANCELED));
        // 配送中不能直接取消，只能送达确认
        ALLOWED_TRANSITIONS.put(OrderStatus.DELIVERING,
                Set.of(OrderStatus.COMPLETED));
        // 已完成只允许进入退款中（售后场景）
        ALLOWED_TRANSITIONS.put(OrderStatus.COMPLETED,
                Set.of(OrderStatus.REFUNDING));
    }

    public static boolean canTransition(OrderStatus from, OrderStatus to) {
        Set<OrderStatus> allowed = ALLOWED_TRANSITIONS.get(from);
        return allowed != null && allowed.contains(to);
    }
}

变更订单状态时，用一条带条件的 UPDATE 语句来保证并发安全，而不是先 SELECT 再 UPDATE：

sql复制UPDATE t_order
SET status = #{toStatus}, version = version + 1, update_time = now()
WHERE id = #{orderId}
  AND status = #{fromStatus}
  AND version = #{version}

如果更新影响行数为 0，说明状态已经被其他请求改过了，这时应该直接抛业务异常，让调用方感知"订单不在可操作状态"。这个模式在用户取消订单、骑手抢单、客服改单时都能复用，是 5.0 里最值得推广的一段代码。

3.2 创建订单与价格快照：绝不能相信前端传来的总价

跑腿订单的价格计算一旦出错，要么用户投诉，要么平台倒贴钱。创建订单的接口设计原则是：前端只传业务因子（起终点坐标、物品类型、重量、小费），价格全部由后端计算并落库。 用户的下单请求结构大致如下：

java复制public class CreateOrderRequest {
    private Long userId;
    private Integer orderType;          // 1帮送 2帮买 3帮办
    private String pickAddress;
    private Double pickLat;
    private Double pickLng;
    private String deliveryAddress;
    private Double deliveryLat;
    private Double deliveryLng;
    private Integer goodsType;
    private Double goodsWeight;
    private String remark;
    private Integer tipAmount;           // 小费，单位分
}

后端的核心动作是计算配送费并生成价格快照：

java复制public PriceSnapshot calculatePrice(CreateOrderRequest req) {
    // 距离来自地图服务，而不是前端传的经纬度直接算，避免坐标被篡改
    DistanceResult distance = gpsClient.calculateDistance(
            req.getPickLat(), req.getPickLng(),
            req.getDeliveryLat(), req.getDeliveryLng());

    int baseFee = 500; // 基础价 5 元，单位分
    int distanceFee = feeRule.calcDistanceFee(distance.getMeters());
    int weightFee = feeRule.calcWeightFee(req.getGoodsWeight());
    int timeFee = feeRule.calcTimeFee(LocalDateTime.now());

    int totalFee = baseFee + distanceFee + weightFee + timeFee + req.getTipAmount();
    return new PriceSnapshot(totalFee, distanceFee, weightFee, timeFee, req.getTipAmount());
}

价格快照生成后，订单表里保存一份完整的费用明细 JSON 字段，同时 amount_total 也被落库。后续无论运营活动、优惠券叠加还是售后退款，都以这份快照为准，避免用户页面上看到的金额和实际账单不一致。

3.3 抢单并发控制：只靠 Redis 锁还不够，Lua 脚本才是关键

跑腿项目最典型的并发场景就是抢单。100 个骑手同时盯着一个优质订单，后端同一瞬间收到大量请求，但最终只允许一个骑手成功。如果只做一个简单的布尔判断再更新，结果一定是多个骑手抢到同一单。

我在 5.0 中实现了"先 Redis + Lua 扣减，再更新数据库"的两层防线。第一层用 Redis 的抢单 token 队列控制总量：

lua复制-- 抢单 Lua 脚本
-- KEYS[1] = order:grab:{orderId} 的 key
-- ARGV[1] = riderId
-- 返回值：1 表示抢单成功，0 表示已被抢走

local existed = redis.call('EXISTS', KEYS[1])
if existed == 1 then
    return 0
end
redis.call('SET', KEYS[1], ARGV[1], 'NX', 'EX', 86400)
return 1

第二层更新数据库订单状态时，SQL 里必须带上 rider_id IS NULL 条件：

sql复制UPDATE t_order
SET rider_id = #{riderId}, status = 2, version = version + 1
WHERE id = #{orderId}
  AND status = 1
  AND rider_id IS NULL

如果 UPDATE 影响行数为 0，说明订单在 Redis 判断之后又被其他请求抢先更新了，此时需要释放 Redis 里的令牌并返回失败。这一套双层校验在实践中把抢单并发冲突降到了接近于零，就算同一订单有上千并发请求，数据库也不会死锁。

提示：Redis 锁只是性能层面的"拦截器"，真正的可靠性最终必须由数据库行锁和乐观锁兜底。任何只靠 Redis 判断、不回查数据库的方案，都存在极端情况下锁过期导致的重复风险。

3.4 超时补偿机制：扫描任务如何安全地自动取消订单

订单超过 15 分钟未支付、已支付但 30 分钟无人接单、骑手接单后 10 分钟未到店，这些场景都需要系统自动干预。5.0 用 XXL-Job 每 30 秒扫一次超时订单，然后通过 MQ 发送超时事件，由订单服务消费事件执行取消或加价操作。

为什么不用 Java 内置定时器？因为生产环境通常是多实例部署，每台机器都执行同一个调度任务会导致重复处理。XXL-Job 的分布式调度能保证同一时刻只有一台机器执行任务，配合任务执行前对订单加分布式锁，基本上可以杜绝重复扫单。

自动取消订单时要非常小心资金安全。已支付订单长时间无人接单被取消，要走原路退款流程，并且必须生成一条退款流水记录。我先在退款表中插入一条状态为"处理中"的记录，再调用微信退款接口，回调成功后再更新这条记录，从而避免退款幂等性问题。

4. 小程序端的关键对接：登录鉴权、支付回调和订阅消息

后端做得再好，小程序端联调时出问题，整体体验一样会崩。5.0 在小程序对接上踩过不少坑，尤其是登录态、支付回调和订阅消息这三个点，我从 3.0 到 5.0 改了不止一遍，这里把最终形成的稳定方案完整展开。

4.1 微信登录流程正确写法：session_key 绝对不能出后端

小程序登录的标准做法是：小程序端调用 wx.login() 拿到临时 code，把 code 传给后端；后端拿到 code 后再去微信接口换 openid 和 session_key。

很多初学项目会把 session_key 返回给前端，然后让前端自己去解密用户手机号或敏感信息，这种做法是错误的。session_key 应该只保存在后端，小程序后续需要解密任何敏感数据时，把加密数据发给后端，由后端统一处理。5.0 的登录实现精简如下：

java复制public LoginResponse wxLogin(String code) {
    // 1. 调用微信接口用 code 换 openid 和 session_key
    WxLoginResponse wxResp = wxClient.code2Session(code);
    if (wxResp == null || wxResp.getOpenid() == null) {
        throw new BusinessException("微信登录失败，请重试");
    }

    // 2. 查询本地用户，如果不存在则注册
    User user = userMapper.selectByOpenId(wxResp.getOpenid());
    if (user == null) {
        user = User.createNew(wxResp.getOpenid(), wxResp.getUnionId());
        userMapper.insert(user);
    }

    // 3. 生成自定义登录 token，并缓存到 Redis，有效期 7 天
    String token = UUID.randomUUID().toString().replace("-", "");
    redisTemplate.opsForValue().set("login:token:" + token, 
            String.valueOf(user.getId()), Duration.ofDays(7));

    return new LoginResponse(token, user);
}

自定义 token 而不是直接使用微信接口返回的凭证，好处是后端可以完全控制登录态的过期策略，也方便后续在管理后台强制踢人下线。

4.2 接口鉴权和签名：跑腿接口为什么需要双重防护

小程序用户端的接口，大部分只需要登录态就行，但有些关键操作比如"修改配送地址权限""骑手提现申请"，如果被恶意用户用抓包工具模拟请求，就会造成严重的越权和资损。

5.0 的通用做法是：后端定义一个 @RequireLogin 注解，所有请求在进入 Controller 之前通过拦截器解析 token，并把当前用户信息放入 ThreadLocal 上下文。骑手端和管理后台各自维护一套独立的权限体系。

对于资金类接口，比如余额充值、骑手提现、大额订单退款，还需要做额外的签名校验。我的做法是从后端下发一个动态随机数，前端在关键操作时要提交一个签名值 SHA256(secret + timestamp + nonce + bizParams)，后端用同样算法校验。这个机制能防止请求被简单重放或篡改参数，实际效果比单纯依赖 HTTPS 更安全。

4.3 微信支付回调的幂等处理：一次失败的回调不能影响订单状态

微信支付成功后请求回调地址，这个回调有很强的重试机制，同一个支付结果可能被微信通知很多次。如果回调接口不幂等，就会导致"同一个支付成功事件被处理两次，订单重复进入待接单池"的线上事故。

5.0 在回调处理中的核心是一张流水表和唯一索引：

java复制@Transactional(rollbackFor = Exception.class)
public void handlePayCallback(PayCallbackRequest request) {
    // 1. 先验签，确认是微信服务器发的
    boolean signValid = wxPayClient.verifySign(request);
    if (!signValid) {
        throw new BusinessException("微信支付回调验签失败");
    }

    // 2. 以 transaction_id 作为唯一键插入支付流水，如果重复插入会走唯一索引报错，直接返回成功给微信
    PayTransaction payTransaction = new PayTransaction();
    payTransaction.setTransactionId(request.getTransactionId());
    payTransaction.setOrderId(request.getOutTradeNo());
    payTransaction.setAmount(request.getTotalFee());
    try {
        payTransactionMapper.insert(payTransaction);
    } catch (DuplicateKeyException e) {
        log.warn("重复支付回调，直接返回成功，transactionId={}", request.getTransactionId());
        return;
    }

    // 3. 通过事务更新订单状态
    Order order = orderMapper.selectByIdForUpdate(request.getOutTradeNo());
    if (order != null && order.getStatus() == OrderStatus.PENDING_PAY) {
        orderMapper.updateStatus(order.getId(), OrderStatus.PENDING_GRAB);
    }
}

关键点在于第 2 步，先通过唯一索引挡住重复回调，再更新订单状态。这样无论微信回调多少次，业务逻辑只执行一次，并且重复回调时直接返回成功，避免微信因为收不到成功响应而无限重试。

4.4 订阅消息推送：配送进度提醒的可靠触达

跑腿小程序里最有价值的产品功能就是配送进度推送，比如"骑手已接单""骑手距您 500 米""物品已送达"。微信小程序不像公众号可以随时推送模板消息，必须由用户主动授权订阅，且一次授权只能发一次。

用户的授权次数、用户是否有新消息、后端如何在下单后触发推送，这些都是细节。我采取的策略是：在用户确认下单并支付成功后，后端会生成一条"消息计划"，预留下单、骑手接单、送达三个触达事件，用户只要在下单流程中点过一次授权，后续这些事件就能依次给他发订阅消息。骑手接单这个动作本身在 order-service，推送动作交给 notification-service 去消费 MQ 消息。即使某个推送通道暂时超时，也不会阻塞主流程，后续可以通过消息重试补发。

5. 距离与计费：把地图 API 和配送规则揉进订单里的正确姿势

很多跑腿项目把配送费设计得太粗暴，直接按直线距离算，结果用户下单时看到 5 元，实际路线距离翻倍，骑手拼命加价，用户体验很差。5.0 把距离计算和费用规则单独拉出来做了一个计费引擎，这里我详细讲一下考虑过程。

5.1 地址解析与坐标处理：不能依赖用户手填的文本

用户端下单时最常见的问题，是用户随手输入一个模糊地址，比如"某某大厦楼下"。如果后端把这个文本直接原样传给地图 API 算距离，结果通常不准确。

比较务实的方案是：小程序端通过 wx.chooseLocation 或腾讯地图 SDK 让用户选择标准 POI 点，返回结构化的地址、经纬度和城市编码。后端强依赖结构化坐标做后续距离计算和骑手导航，不直接信任用户手填文本。

如果必须允许文字输入地址，后端要调用一次地图解析接口，把文本解析成经纬度并且回填标准地址。这一步不仅是为了算距离，更是为了防止恶意用户传一个根本不存在的坐标，导致骑手白跑一趟。

5.2 配送费阶梯规则：按距离、重量、时段、天气动态组合

5.0 的配送费分成四个部分：

实现这个规则时，我没有把它写死在业务代码里，而是做成了一张配置表，运营后台可以随时调整。因为跑腿业务在不同城市、不同季节会有完全不同的运力成本，死代码只能改版本发布，配置表则可以实时生效。计费引擎的核心逻辑是启动时把配置加载到本地缓存，计算价格时先查缓存，配置变更通过 MQ 广播刷新缓存。

5.3 骑手实时位置：Redis GEO 与附近骑手查询

骑手端每 3 到 5 秒会上报一次 GPS 坐标。如果每次都写 MySQL，订单高峰期会造成巨大的写压力。5.0 把骑手最新坐标放到了 Redis 的 GEO 结构里，每个骑手 ID 对应一个坐标成员：

bash复制GEOADD rider:location 116.397 39.908 rider_1001

当用户下单时，系统需要找到起点附近可接单的骑手数量，来决定是否推送接单通知，可以用：

bash复制GEORADIUS rider:location 116.397 39.908 3 km COUNT 10

这样查询附近骑手非常快，3 公里内的骑手在几十毫秒内就能返回。需要持久化轨迹时，再把这批历史坐标异步写入 MongoDB 或 MySQL 轨迹表，不会影响主链路的响应时间。

注意：Redis GEO 只能存最新坐标，无法支撑回放轨迹和里程统计。如果后续要做骑手轨迹回放、配送里程审计，必须把原始 GPS 数据落库，建议按天分表，同时加一个 userId+time 的联合索引。

6. 线上故障复盘：四类直接影响跑腿平台口碑的问题与处理

这部分是全文最值钱的段落。5.0 上线后的头两个月，我们确实被一系列问题打脸过，下面四个问题都属于"不影响则已，一影响就是大事"的类型。我把排查过程和最终规避措施完整写出来，希望大家不用再踩一遍。

6.1 两个骑手同时抢同一单：从 Redis 锁到数据库更新的完整排查

现象：线上监控发现偶尔有骑手反馈"我明明抢到了订单，App 里却消失了"。查日志发现两个骑手都对同一个订单走到了支付完成回调后的派单流程。

原因排查链路是这样走的：第一版抢单代码只用了 Redis 的 SETNX 做互斥，Redis 里设置了这个单被谁抢到。但 Redis 锁存在过期时间，如果处理线程在锁过期后还没有完成数据库更新，另一个请求就能拿到同一个锁。更隐蔽的问题是，Redis 锁删除时没有检查是不是自己的锁，A 线程处理慢了，B 线程抢到锁，A 线程之后删锁把 B 的锁误删，C 再抢，最终被 C 抢走。

这个问题最终的解决方案有三层：

1. Redis 锁的 value 必须携带线程唯一标识，删锁时先比较 value 再删。
2. 数据库 UPDATE 语句中加入 rider_id IS NULL 条件，以数据库为准做最终裁决。
3. 锁过期时间不能设置得太短，要大于一次数据库事务的正常执行时间，我一般设置 10 秒。

线上再没出现过一单多骑手。如果遇到类似问题，排查时建议先看数据库订单表是否有两个更新记录，再看 Redis 锁删除的日志顺序，基本能快速定位。

6.2 支付回调重复到账：看"幂等键"为什么比删除操作更可靠

第二个典型的线上问题是：有用户在支付成功后，系统给他补发了一次骑手优惠券；另外还有一例是用户取消订单后再支付，订单状态直接变成"待接单"，骑手出现时用户很懵：我明明取消了。

核心原因还是在回调幂等设计上。早期实现是每次回调先查询订单当前状态，如果不是"待支付"就直接返回成功，看起来合理，但漏掉了"查询订单"和"更新订单"之间发生的并发操作。一旦回调线程和用户取消线程同时操作同一个订单，就会出现状态覆盖。

修正方案就是我在 4.3 里写的那套逻辑：以支付流水表的唯一索引为拦路石，任何回调先尝试插入流水，重复插入直接返回成功，不触发后续业务。同时取消订单的逻辑必须要求当前状态是"待支付"才能取消，如果订单已经变成"待接单"，就要走"取消已支付订单"的退款流程，不能强行置为取消。

6.3 一个 COUNT 慢 SQL 是怎么把数据库连接池拖垮的

有一次大促活动，业务量只有正常的两倍，但订单服务报警数据库连接池耗尽，几乎整个后端不可用。查看慢查询日志，发现罪魁祸首是一个统计接口：管理后台首页需要展示"今日订单总数、待接单数、骑手在线数"，当时是直接用一条 JOIN 查询实时去 MySQL 里 COUNT。

问题在于这个接口被前端的轮询逻辑每 10 秒请求一次，高峰期 COUNT 又要扫描几十万条订单记录，几个统计接口叠加后，数据库连接全部被慢 SQL 占住，正常下单的写请求拿不到连接。

解决方式很简单：

• 把统计型查询从主库切到只读从库；
• 首页数值改成每 5 分钟缓存一次，而不是实时查数据库；
• 订单表的统计查询改成走汇总表，每日凌晨由 XXL-Job 汇总，首页默认展示前一天的汇总值。

这是一条很通用的经验：任何面向运营后台的列表页和统计页，都不应该直接在大表上实时 COUNT。报表走汇总表，搜索走 Elasticsearch，才是扛住线上流量该有的姿势。

6.4 地图 API 坐标偏差：轨迹看着正常，实际距离却差出一公里

坐标系统是我觉得最阴间的坑。小程序端拿到的经纬度通常是 GCJ-02 坐标，而部分地图服务的算路接口默认接收 WGS-84 坐标，如果不做转换，同样两个点算出来的距离可能偏差 10% 以上。配送费是按距离算的，如果每单都多算几百米，用户对价格就很敏感；如果少算，骑手就吃亏。

5.0 的做法是统一在后端保存"业务坐标"，所有端上报的坐标先经过坐标系转换工具转成统一坐标系，然后再进入距离计算和路线规划。同时每次创建订单时，把地图服务返回的实际规划距离缓存下来，用户发起售后纠纷时，可以拿这份距离作为仲裁凭证。坐标转换看似是小事，但在跑腿这种每单都要算钱的业务里，它是直接影响毛利的细节。

7. 部署上线与单城市运营：一套足够稳定又便宜的落地方案

最后聊部署和运营。很多项目死不是死在代码上，而是死在"上线后没人管、出问题不知道、扩容不会扩"这些工程化细节上。跑腿业务有非常明显的高峰低谷，如果为了应付 10 分钟的高峰买一堆高配服务器，是纯浪费钱。

7.1 服务器配置与反向代理：从本地联调到生产环境

5.0 在本地开发时，后端服务分别跑在 8080 等端口，小程序开发者工具里可以勾选"不校验合法域名"直接联调。但一旦发布体验版，就必须在小程序后台配置 HTTPS 请求域名，并且域名下所有 API 都要走 443 端口。

生产环境我建议的起步配置是一台 4 核 8G 的应用服务器 + 一台 4 核 8G 的数据库服务器 + 一台 2 核 4G 的中间件服务器。数据库服务器单独放一台，避免 Java 应用内存抖动影响数据库性能。前面用 Nginx 做反向代理，配置好 HTTPS 证书，并把 /api/order、/api/user 等路径分别代理到不同的微服务实例上。

7.2 JVM、线程池、连接池的参数调整

不要迷信默认配置。不同服务的 JVM 参数应当有区别。像 order-service 这种核心交易服务，我给的堆内存是 2G，新生代 1G，并且开启 -XX:+UseG1GC；像 notification-service 这种 IO 密集型服务，核心线程池可以设置得较大，堆则不需要太高。

MySQL 连接池在 Spring Boot 中建议核心线程数设置为 10~20，最大连接数设置为 30~50，太小容易排队，太大会让数据库本身的线程切换开销增大。Redis 连接池也有同样的问题，建议最大连接数不要超过 50。网络请求超时时间统一设置 3 秒，连接超时 1 秒，别让一个慢接口拖垮整个线程池。

7.3 日志、告警和人工兜底：上线首月最容易忽略的事

日志规范做不好，线上问题排查效率至少降低十倍。5.0 的每一笔订单都会打印一条包含订单号、用户 ID、骑手 ID、操作类型、时间戳的结构化日志，排查问题时直接以订单号为关键字搜索，整个流程就出来了。

告警方面，最重要的三个指标是：接口 5xx 比例、订单支付成功后的回调延迟、抢单成功接口耗时。任何一个指标超过阈值就立刻告警。上线首月，我强烈建议安排一名后端同学值班盯群，因为有大量问题是告警规则覆盖不到的，比如骑手反馈定位不准、用户反馈明明付了钱但订单没生成。这类反馈需要有人工客服通道能快速介入，通过订单号在后台查询完整的操作日志，才能快速判断是用户问题还是系统缺陷。

以我自己用 5.0 落地单城市运营的经验来说，技术指标是否达标反而不是最让人焦虑的，真正会让团队崩溃的永远是"用户已经投诉了，但开发还不知道问题出在哪个环节"。所以无论你的项目阶段多早期，订单号的全局日志、统一的异常码、状态机流转表这三样一定要从第一天就建立起来。拿这套结构去支撑一个城市每天几千单量级的跑腿业务，完全是够用的，而且后续想复制到第二个城市时，你只需要在订单表上增加城市分片字段，核心逻辑都不用改。