同城配送调度系统微服务实战：从订单状态机到分布式锁

同城配送调度系统我前前后后做了两版，第一版是单体应用，第二版才拆成微服务。说实话，这个业务场景非常适合聊微服务，因为它的核心矛盾太典型了：午晚高峰流量瞬间冲高、订单状态流转频繁、骑手和订单之间的实时匹配对延迟极度敏感。如果你正在准备 Java 面试、打算用微服务重构自己的项目，或者单纯想搞明白同城配送这类系统到底是怎么调度的，这篇文章应该能给你不少能直接用的东西。

我不会把源码从头贴到尾，那不现实也没必要。我更想讲清楚的是：技术选型为什么这么定、数据库到底怎么设计、抢单和派单背后的并发控制怎么做、微服务之间的数据一致性怎么保证。这些都是我在实战里踩过坑、在线上验证过的方案，你拿去参考，至少不会走弯路。

1. 系统整体架构与微服务拆分思路

1.1 单体为什么撑不住，选型时机怎么判断

很多人一上来就问“微服务怎么拆”，但我建议先回答另一个问题：这个阶段值不值得拆。

同城配送第一版是典型单体，订单、骑手、计价全部在一个 Spring Boot 工程里。日均几千单的时候，单体完全没问题，一台 4C8G 的服务器都能跑。真正撑不住的点有三个：

• 午高峰和晚高峰流量是平峰的十几倍，单点扩容只能升配不能横扩，成本越拉越高。
• 下单、调度、计价、推送的代码全部耦合在一个工程里，改计价规则要重启整个服务。
• 关键链路的稳定性被非核心功能拖累，比如短信推送服务一抖动，订单接口也跟着超时。

但我要泼一盆冷水：如果日单量没过万，团队也没几个人，我劝你先别拆。微服务是把双刃剑，拆出来的每个服务都有网络开销、部署成本、排查链路的问题。同城配送这种场景适合微服务，是因为业务域天然边界清晰，不是因为微服务本身有什么魔力。

决定拆的时候，拆分的时机最好选在业务扩张、需求开始并行增多的阶段。我见过很多团队在系统还很小的时候硬拆，结果开发效率反而更低，光服务联调和环境部署就耗掉大量时间。

1.2 按什么边界拆分，落地成哪些服务

边界怎么划？我一般记住三句话：业务能力优先、数据归属清晰、变更频率分离。

基于这个原则，同城配送系统我拆成了下面几个核心服务。

每个服务拥有自己的数据库，这是微服务能不能落地的关键。你只要出现“订单服务直接查骑手表”的念头，就要停下来重新审视边界。跨服务的数据协作一律走接口或消息，不能因为图省事就把数据源打通，否则拆完的耦合度比单体还难受。

顺带提一句，现在很多人直接用若依微服务版这类脚手架做二开。脚手架能帮你省下搭建时间，但拆分逻辑、表结构还是得自己理解透彻，否则后面对接业务需求时改动成本非常大。

1.3 技术栈选型与版本匹配

技术栈我在两版系统里对比过，最终稳定跑线上的是这套组合：

• 微服务框架：Spring Cloud Alibaba
• 注册与配置中心：Nacos
• 网关：Spring Cloud Gateway
• 远程调用：OpenFeign
• 限流熔断：Sentinel
• 消息队列：RabbitMQ
• 缓存/分布式锁：Redis
• 数据库：MySQL 8.0
• 对象存储：MinIO（放骑手证件、配送凭证图片）
• 部署方式：Docker Compose + 少量 K8s

这里最容易被忽略的是版本匹配。Spring Boot、Spring Cloud、Spring Cloud Alibaba 三者必须对齐，否则启动就是一堆莫名其妙的报错。我线上用的组合是 Spring Boot 2.7.x + Spring Cloud 2021.0.x + Spring Cloud Alibaba 2021.0.5.0，这套是经过大量项目验证过比较稳的组合。

注意：不要盲目追新版本。微服务基础设施讲究的是稳定兼容，新版本带来的新特性对你这个系统大概率用不上，但升级带来的兼容性问题能让你排查到怀疑人生。

2. 核心业务模型与数据库设计

2.1 订单状态机，用一张表撑起全流程

同城配送订单的状态流转是整个系统的骨架，我强烈建议你从一开始就用状态机约束，而不是在业务代码里到处写 if 判断。

订单的核心状态链路是这样的：

创建订单 -> 支付成功 -> 待调度 -> 已接单（抢单/派单成功） -> 已取件 -> 配送中 -> 已送达

其中还有一个贯穿全程的分支：取消。支付前用户可以取消，调度中运营可以取消，接单后如果骑手迟迟不取件，系统也会走取消流程。

状态机在 Java 里的落地方式有几种，轻量级的用枚举加一个 Map 就够了，不用为了状态机单独引入框架。核心代码示意：

java复制public enum OrderState {
    CREATED, PAID, PENDING_ASSIGN, ASSIGNED, PICKED_UP, IN_TRANSIT, DELIVERED, CANCELLED;

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

    static {
        TRANSITIONS.put(CREATED, EnumSet.of(PAID, CANCELLED));
        TRANSITIONS.put(PAID, EnumSet.of(PENDING_ASSIGN, CANCELLED));
        TRANSITIONS.put(PENDING_ASSIGN, EnumSet.of(ASSIGNED, CANCELLED));
        TRANSITIONS.put(ASSIGNED, EnumSet.of(PICKED_UP, CANCELLED));
        TRANSITIONS.put(PICKED_UP, EnumSet.of(IN_TRANSIT));
        TRANSITIONS.put(IN_TRANSIT, EnumSet.of(DELIVERED));
    }

    public boolean canTransferTo(OrderState target) {
        Set<OrderState> next = TRANSITIONS.get(this);
        return next != null && next.contains(target);
    }
}

有了这张流转表，你在任何服务里做状态变更前，先调 canTransferTo 校验，非法流转直接拒绝。这样即使 MQ 消息重复投递，或者接口被并发调用，状态也不会被篡改成不可能的组合。这对后面的幂等设计帮助很大。

2.2 骑手、调度记录核心表设计

订单表是系统主表，但我更想提醒你注意几个容易被忽略的字段设计。

sql复制CREATE TABLE t_order (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL COMMENT '业务订单号',
  user_id BIGINT NOT NULL COMMENT '用户ID',
  courier_id BIGINT DEFAULT NULL COMMENT '接单骑手ID',
  dispatch_type TINYINT NOT NULL COMMENT '调度方式 1-抢单 2-派单 3-转派',
  status TINYINT NOT NULL COMMENT '订单状态',
  from_lng DECIMAL(10,6) NOT NULL COMMENT '起点经度',
  from_lat DECIMAL(10,6) NOT NULL COMMENT '起点纬度',
  to_lng DECIMAL(10,6) NOT NULL COMMENT '终点经度',
  to_lat DECIMAL(10,6) NOT NULL COMMENT '终点纬度',
  geo_hash VARCHAR(12) NOT NULL COMMENT '起点GeoHash编码',
  amount DECIMAL(10,2) NOT NULL COMMENT '订单金额',
  pay_status TINYINT NOT NULL COMMENT '支付状态',
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  UNIQUE KEY uk_order_no (order_no),
  KEY idx_status_time (status, created_at),
  KEY idx_courier_status (courier_id, status)
) COMMENT='配送订单表';

经纬度为什么用 DECIMAL 而不是用字符串？因为要参与距离计算和展示，DECIMAL(10,6) 的精度足够支持米级距离计算了。GeoHash 字段非常重要，后面做“查附近骑手”“查附近订单”都靠它。

骑手表和调度记录表的设计相对简单，但有几个点要说一下。骑手当前坐标不要长期落 MySQL，MySQL 只存最新的经纬度和状态，实时坐标走 Redis。调度记录表每次抢单派单都要写一条，包括调度类型、候选骑手列表、最终骑手、触发原因，这些数据后面复盘算法效果、排查调度问题都是第一手依据。

2.3 计价规则配置化，避免改代码

配送费计价的坑比你想的多：起步价、每公里加价、重量加价、雨天加价、夜间加价、远距离加价叠在一起，如果不做配置化，每次调价都要发版，上线后还容易改错。

我这边把计价规则拆成了两张表：计费规则主表和规则明细表。主表存城市、生效时间段、车型等维度，明细表存计价阶梯。pricing-service 启动时把规则缓存到本地，订单创建时根据城市、当前时间、距离、重量计算费用。

计价核心代码大致是：

java复制public BigDecimal calculatePrice(PriceContext ctx) {
    BigDecimal amount = rule.getBasePrice(); // 起步价
    // 超过起步里程的部分按每公里的单价累加
    if (ctx.getDistance() > rule.getBaseDistance()) {
        BigDecimal extraDistance = ctx.getDistance() - rule.getBaseDistance();
        amount = amount.add(extraDistance.multiply(rule.getPerKmPrice()));
    }
    // 天气、时段、重量加价
    amount = amount.multiply(ctx.getTimeFactor()).multiply(ctx.getWeatherFactor());
    return amount.setScale(2, RoundingMode.HALF_UP);
}

金额计算里最容易出的问题是精度。所有费用字段一律用 BigDecimal，禁止用 double。我在第一版就吃过亏，double 算出来的金额出现 19.999999 这种结果，直接导致用户对账不平。别嫌麻烦，BigDecimal 的写法是对的。

3. 调度算法落地：抢单、派单与兜底

调度是同城配送系统的灵魂，也是整个项目里最值得拿出来讲的部分。调度模式我分三种：骑手主动抢单、系统智能派单、超时兜底转派。三种模式并存，互相兜底。

3.1 抢单并发控制，Redis Lua 保证一单一骑手

最经典也是最刺激的场景来了：一个订单同时推给附近 50 个骑手，50 个人同时点抢单，但订单只有一个，最终只允许一个骑手成功。

第一版我用的方案是数据库乐观锁，一条 SQL 搞定：

sql复制UPDATE t_order SET courier_id = #{courierId}, status = 2, updated_at = NOW()
WHERE id = #{orderId} AND status = 1;

MySQL 行锁保证了同一时刻只有一个 UPDATE 成功，affected 为 1 就说明抢到了。这个方案在低并发时很稳，问题是高峰时段订单量大，大量 UPDATE 请求同时打在热点行上，数据库连接和锁等待容易顶不住。

后面优化成 Redis + Lua 脚本做前置判断，只有拿到锁的骑手才允许打数据库，数据库压力直线下降。核心脚本长这样：

lua复制-- KEYS[1]: order:lock:{orderId}
-- ARGV[1]: courierId
-- ARGV[2]: 锁过期时间（秒）
if redis.call('SET', KEYS[1], ARGV[1], 'NX', 'EX', ARGV[2]) then
    return 1
else
    return 0
end

在 Java 侧用 RedisTemplate 执行：

java复制public boolean tryGrabOrder(Long orderId, Long courierId) {
    String lockKey = "order:lock:" + orderId;
    String lua = "if redis.call('SET', KEYS[1], ARGV[1], 'NX', 'EX', ARGV[2]) then return 1 else return 0 end";
    Long result = redisTemplate.execute(
        new DefaultRedisScript<>(lua, Long.class),
        Arrays.asList(lockKey),
        courierId.toString(),
        "10"
    );
    return result != null && result == 1L;
}

抢锁成功后再走数据库更新，同时把锁过期时间设短一点，保证即使业务处理失败锁也能自动释放。这里有个细节：锁的过期时间要结合业务耗时设置，太短会导致第一笔业务还没处理完锁就过期，太长会阻塞正常转派流程。我这里设置的是 10 秒，实际处理都在几十毫秒内完成，完全够用。

3.2 智能派单的加权评分模型

抢单适合单量密度高、骑手多的商圈。一旦跑到郊区或凌晨，就得靠系统派单。派单的核心是给每个候选骑手打分，分高者得。

评分模型不需要一开始就上机器学习，用加权公式就能解决大部分问题。我的评分公式是：

code复制score = w1 * (1 / 距离) + w2 * (骑手评分 / 5) + w3 * (1 / (当前单量 + 1)) + w4 * 顺路度

四个因子分别代表：距离越近越好、评分越高越好、手里单越少越好、顺路优先。默认权重是 0.5、0.3、0.2，再加上顺路度作为加分项。权重不能写死在代码里，要放到配置中心，运营同学可以随时调，每次调完看数据反馈再迭代。

实现代码如下：

java复制public List<Courier> rankCouriers(DispatchContext ctx, List<Courier> candidates) {
    return candidates.stream()
        .map(c -> {
            double distanceScore = 1.0 / Math.max(ctx.distanceTo(c), 0.1);
            double loadScore = 1.0 / (c.getActiveOrderCount() + 1);
            double score = 0.5 * distanceScore
                    + 0.3 * c.getRating() / 5.0
                    + 0.2 * loadScore;
            if (c.isOnRoute(ctx.getTargetPoint())) {
                score += 0.1;
            }
            c.setScore(score);
            return c;
        })
        .sorted(Comparator.comparingDouble(Courier::getScore).reversed())
        .limit(10)
        .collect(Collectors.toList());
}

这里用 Java 8 的 Stream 和 Lambda 处理排序，代码简洁，面试聊到这块还能顺带展示你对函数式编程的掌握。顺路度判断就是对比骑手当前方向向量和订单方向向量的夹角，夹角越小越顺路。

派单打分定下来后，最终确认接单不能只看分数。系统先把订单推送给分数最高的前 3 个骑手，先确认先得，超时 30 秒未确认就自动滑向下一位，避免因为一个骑手手机没电导致订单卡死。

3.3 超时未接单的兜底与转派

做调度一定要做最坏的打算。订单推出去 1 分钟没人抢、没人派成功，怎么办？我这边设计了三级兜底：

• 第一级：自动扩大推送半径，从 2 公里扩到 3 公里、5 公里，同时提高订单小费。
• 第二级：直接指派给评分最高且空闲的骑手，发强提醒。
• 第三级：通知运营人工介入，后台手动改派。

这套逻辑用一个定时任务驱动，对每个处于待调度状态超过阈值的订单做检查。定时任务用 Spring 的 @Scheduled 实现，每 10 秒扫描一次。但有个致命问题：微服务多节点部署时，同一时刻可能有两个节点同时在跑这个任务，导致订单被重复处理。

解决方式有两种，要么引入分布式锁，要么用 MQ 延迟消息触发。我最终采用的是 Redis 分布式锁 + 定时任务，代码上给任务加锁，保证同一时刻只有一个节点执行：

java复制public void checkDispatchTimeout() {
    String lockKey = "job:dispatch-timeout-check";
    boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(30));
    if (!locked) {
        return;
    }
    // 执行兜底逻辑
}

这个方案简单有效，30 秒的过期时间能覆盖任务执行时长，万一节点崩溃锁也会自动过期释放，不会造成死锁。

4. 微服务通信、分布式事务与幂等实战

4.1 同步 RPC 加异步消息的链路设计

微服务拆分后，服务间通信成了设计和排查的重灾区。我遵循两条基本原则：

• 下单、支付、抢单这些用户强感知的链路，用同步 RPC，保证即时反馈。
• 派单后的状态同步、消息推送、转派重试这些内部协作，全部走 MQ 异步化。

以用户下单为例，网关把请求转到 order-service，order-service 需要先同步调用 pricing-service 拿到配送费，然后落库返回“待支付”，这段链路是同步的，因为用户必须立刻看到价格。支付成功后，order-service 发一条“支付成功”消息到 RabbitMQ，dispatch-service 监听这个消息，开始调度；调度成功后再发“订单已接单”消息，message-service 监听后给用户推送服务号通知。

用 MQ 替代同步 RPC 的好处是链路短、解耦彻底。下单服务不会因为推送服务慢而被拖垮，推送服务的任何抖动也不影响核心链路。当然代价是引入了消息中间件的运维成本和消息丢失风险，所以可靠投递必须配合下面的机制来做。

4.2 本地消息表解决分布式事务

同城配送里最典型的分布式事务场景：支付成功，订单状态更新，同时要创建调度任务。如果这些问题在三个服务里各自操作，任何一个失败都会造成数据不一致。

我第一版想过直接用 Seata 的 AT 模式，全局事务确实方便，但引入后对数据库性能有影响，而且事务时间长会放大锁冲突。最终选了最原始也最可靠的“本地消息表 + 定时任务”方案。

流程是这样的：

1. 订单服务在本地数据库的一个事务里，写完订单状态变更，同时向 t_message 消息表插入一条待发送消息。
2. 定时任务扫描消息表，把状态为“待发送”的消息投递到 RabbitMQ。
3. dispatch-service 消费消息后执行调度逻辑，处理成功后调用订单服务接口确认，订单服务把消息状态标记为“已确认”。
4. 消息投递失败的，定时任务会重试，多次重试仍然失败的进入死信队列供人工排查。

这套方案已经被验证了很多年，优点是逻辑透明、可控性强，不依赖额外组件（消息表就在订单库里）。缺点是需要自己维护消息表的写入和确认，代码量多一些，但换来的是极高的可靠性。

4.3 MQ 重复消费与接口幂等

RabbitMQ 的消费确认机制是“至少一次”，也就是说在生产端、消费端任何一环出问题，消息都可能被重复投递。如果你的消费逻辑没有幂等处理，就会出现同一个订单被派给两个骑手的严重事故。

幂等设计的三个抓手：

• 基于业务键的唯一约束：调度记录表中给 order_no 建唯一索引，重复插入直接报错，捕获 DuplicateKeyException 后按幂等处理。
• 基于 Redis 的去重：消费前先 SETNX 一个业务处理标记，处理完成再设置状态，重复消息直接跳过。
• 基于状态机的校验：订单只有处于“待调度”状态才能被派单，即使消息重发，第二次执行时状态已经变了，直接拒绝即可。

我实际用三管齐下的方案，重点靠数据库唯一约束，Redis 做前置过滤，状态机做最后防线。微服务的线上环境什么怪事都能发生，多几层保险比事后补救强得多。

5. 高并发性能优化实录

5.1 骑手定位与热点数据缓存

骑手坐标是这个系统里更新最频繁的数据。高峰期几千个骑手，每 5 秒上报一次定位，如果全部直接写 MySQL，数据库会被写入请求打爆，读到的还是旧数据。

我的方案是：实时坐标全部放 Redis，用 GEO 数据结构存储。骑手 GPS 上报接口只写 Redis，业务读取附近骑手也走 Redis 的范围查找。核心命令：

bash复制# 记录骑手坐标
GEOADD courier:geo 116.404 39.915 courier_1001
# 查找某点 3 公里内的骑手，按距离排序
GEOSEARCH courier:geo FROMLONLAT 116.404 39.915 BYRADIUS 3 km ASC COUNT 20

Redis 6.2 以上的 GEOSEARCH 非常方便，一次调用就能拿到范围骑手列表。查询到候选骑手后，再回 MySQL 查骑手的评分、当前单量等业务指标，把热点数据的读压力全部挡在 Redis 层。

热点订单数据同理。订单详情用户会反复刷新，我把最近 10 分钟创建的订单缓存到 Redis，查询走缓存，落库异步进行。缓存淘汰用简单的过期时间，订单进入已送达状态后设置短暂缓存即可，没必要把历史订单都塞进 Redis。

5.2 分布式锁选型与演进

分布式锁在抢单、定时任务、账户扣减里都用到。演进路线我自己走过一遍，从 synchronized 到 Redis SETNX 再到 Redisson，每一步都有明确的驱动原因。

单节点时代你确实可以用 synchronized，但微服务部署了多节点，JVM 锁只对当前进程内的线程生效，跨节点的并发控制必须用分布式锁。最基础的 Redis 分布式锁就是 SETNX，但要注意不能只 SETNX 不设过期时间，否则获取锁的节点宕机后锁永远不会释放。

Redisson 在纯 SETNX 基础上帮你处理了自动续期的问题，它有个看门狗机制，默认锁超时时间 30 秒，业务没执行完会自动续期，不用自己设置过期时间。抢单和定时任务我用 Redisson 的 tryLock 就够了。

更复杂的 RedLock 多节点锁方案在行业内争议较大，我建议绝大多数业务系统慎用。同城配送场景完全没有必要引入 RedLock 这种复杂度，因为它带来的高可用收益远不如简单可靠的单 Redis 锁。除非你的系统对数据一致性要求高到银行级别，否则不要过度设计。

5.3 数据库索引、分表与读写分离

数据库优化这块，我踩过的最大的坑是“附近订单”查询。如果直接用经纬度计算距离（比如 HAVERSINE 公式）然后排序，数据量一上来就是全表扫描，慢查询日志一分钟刷好几屏。

优化思路是用 GeoHash 前缀匹配。GeoHash 把二维经纬度编码成一维字符串，前缀相同的表示距离相近。查询附近订单时，先用订单起点 GeoHash 前 6 位做前缀匹配，圈定一个小的候选集，再在候选集里精确计算距离排序。SQL 大致长这样：

sql复制SELECT * FROM t_order
WHERE geo_hash LIKE 'wx4g0b%'
AND status = 1
ORDER BY created_at DESC
LIMIT 50;

这样查询的数据量从几十万级降到几百级，慢查询直接消失。

数据量再大一些，按城市分库分表是必然选择。同城配送天然有城市属性，我采用按城市 ID 作为分片键，把不同城市的数据路由到不同库。分片后跨城市的查询需求几乎没有，所以这个分片策略非常契合业务。

读写分离我放在了最后一步，因为引入主从复制会增加数据延迟的问题。核心链路尽量读主库，实时性要求不高的统计查询走从库，避免因为主从延迟导致用户看到的数据不一致。

6. 部署、监控与运维细节

6.1 一套能跑起来的开发环境

微服务项目最劝退新人的往往不是代码，而是环境。Nacos、MySQL、Redis、RabbitMQ 一个都不能少，手动装一遍能折腾一整天。我用 Docker Compose 把基础设施一键拉起来，本地开发效率高不少。下面是精简版的编排文件：

yaml复制version: "3"
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root123
    ports:
      - "3306:3306"
    volumes:
      - ./mysql/data:/var/lib/mysql
  redis:
    image: redis:7
    ports:
      - "6379:6379"
  rabbitmq:
    image: rabbitmq:3-management
    ports:
      - "5672:5672"
      - "15672:15672"
  nacos:
    image: nacos/nacos-server:v2.2.3
    environment:
      MODE: standalone
    ports:
      - "8848:8848"

本地环境有一点要提：JDK 和 Maven 的环境变量配置是很多新手的第一道坎。JAVA_HOME 必须指向 JDK 安装目录，而不是 JRE 目录；PATH 里要加上 %JAVA_HOME%\bin。我见过太多人 JAVA_HOME 配错导致启动就报 “Unable to locate the JVM” 或者明明装了 JDK 17，项目却用 JDK 8 编译的情况。建议本地尽量固定用 JDK 8 或 11 跑 Spring Cloud Alibaba 的项目，省去很多版本兼容问题。

6.2 核心监控指标与告警

微服务拆完之后，如果不做监控，排查问题就像大海捞针。我重点盯这几个指标：

• 接口维度的 QPS、RT、出错率，特别是下单、抢单、支付回调三个核心接口。
• MQ 的积压数量，消费积压超过阈值意味着管道堵了，通常是消费端出问题。
• 服务的 GC 时长和频率，Full GC 频繁会直接影响接口 RT。
• 调度成功率，即订单从待调度变成已接单的转化率，这是业务健康度的重要指标。

告警统一推到钉钉或者企业微信机器人，按 P1/P2/P3 分级。P1 级是核心链路不可用，比如下单成功率连续 10 分钟低于 90%，要求立刻响应；P3 级是边缘指标异常，只记录不打扰。

有条件的尽量把日志接入 ELK 或用 Loki 做日志聚合，不然服务一多，日志文件分布在不同机器上，查一个问题要跳好几台服务器，效率极低。

7. 常见问题与排查技巧实录

7.1 编译与运行期经典报错汇总

微服务项目开发中遇到报错太正常了，我把高频问题整理成一张表，都是实际调试过、确认过解决方案的：

这里重点说一下 RedisTemplate.increment 那个坑。我当时是用 Redis 做骑手日接单计数，把一个字符串类型的值误写成了 “abc”，调用 increment 直接抛异常。排查好久才发现是之前测试数据污染了 key。建议线上用固定的 key 前缀 + 明确的数据类型规范，禁止混用。

7.2 并发业务场景的坑

除了编译问题，并发场景下的业务坑更隐蔽，也更致命。我挑三个印象最深的来说。

第一个是双节点定时任务重复处理。某次凌晨促销活动，两个 dispatch-service 节点同时执行超时检查任务，同一批订单被重复处理，导致部分用户订单被派了两次。当时还没有加分布式锁，只能紧急上线修复。后来我给所有定时任务统一加了 Redis 锁，锁的过期时间必须大于任务实际最大执行时间，否则任务还没跑完锁就没了。

第二个是 MQ 重试机制引发的消息风暴。RabbitMQ 默认会对消费失败的异常消息做重试，如果消费者代码里对一条坏消息始终处理失败，就会无限进入死循环，不仅堆积大量日志，还把下游接口打挂。解决办法是手动确认模式 + 重试次数限制，超过 3 次直接进入死信队列等待人工处理。

第三个是热点订单导致的 MySQL 锁等待。大促时单个热门订单可能同时被几十个请求尝试改为已接单，虽然我们的业务上只允许一个骑手抢单成功，但大量的 UPDATE 落在同一行上，还是会造成行锁争用。后来把抢单的入口流量全部用 Redis 前置过滤，数据库的锁等待时间降了非常多。

经验总结下来就一句话：微服务架构里，问题往往不是被某一个服务单独扛住的，而是通过多级防护体系层层把关。每一层都要有自己的兜底逻辑，这样才不会出现单点故障。

关于这套系统，我最后的体会是：调度本身的算法复杂度并没有高到不可实现，真正考验人的是并发控制、数据一致性、消息可靠性和排查线上问题的能力。这些能力不是看几篇面试题就能掌握的，一定得自己在真实项目里踩坑、复盘，才会有感觉。如果你也在做类似的微服务实战项目，先把订单状态机、抢单并发控制、本地消息表这三块啃透，系统的地基基本就稳了。