订单派发高并发优化实战：Redis锁、RocketMQ与抢单架构

最近我刚把公司跑腿平台的订单派发模块从头到尾做了一轮高并发优化，从最初高峰期接口超时、订单丢失、骑手抢单抢出脏数据，到压测扛住QPS翻了几倍，中间踩的坑够写一篇长文了，所以趁着还没忘干净，把方案和代码一起沉淀下来。这个过程不算多高级，但足够真实，适合手上正在做同城配送、外卖聚合、代买代送业务，或者正在准备Java高并发面试的朋友参考。

整个项目的核心就是一句话：在大量订单短时间内涌入、骑手同时在线的场景下，如何保证一笔订单被正确、快速、不重复地派出去，同时配送管理这条链路不能被压垮。这里面牵扯到的不只是加个Redis锁或者换台数据库那么简单，而是从业务模型、并发控制、消息削峰、存储设计到最后的故障排查，整套都要重新捋一遍。

1. 跑腿平台的业务模型与技术挑战

1.1 从下单到完成：跑腿订单到底是怎么流转的

跑腿业务看起来很简单，用户下一个单，骑手去取件再送到目的地，但实际落地的业务链路比想象中要长得多。一个典型的即时配送订单会经过这些节点：用户提交订单并支付、订单中心创建订单、支付回调确认、订单进入待派单池、派单中心匹配骑手、推送订单给候选骑手、骑手抢单/系统指派、骑手到店取件、骑手送达、用户确认完成。

这里面最容易被忽视的是订单状态的多样性。除了正常流程，还有用户取消、超时未支付自动关闭、骑手抢单后用户取消、配送中改地址、异常拒收、超时赔付等等。每一种异常分支都意味着状态要发生迁移，而状态迁移又往往伴随着并发写操作。比如用户和骑手同时操作一笔订单——用户点取消，骑手点接单，这两个请求几乎同时到达后端，如果处理不好，就会出现订单既被取消又被接单的脏数据。

跑腿业务还有一个特点：强位置属性。每一笔订单都带有取件地址、送达地址，骑手也有实时位置。这导致系统里大量查询是“以某个坐标为中心，找半径N公里内的骑手”这种地理空间查询，在高并发下如果每次都直接扫数据库，非常容易拖垮整个订单库。

在动手优化之前，我先把全链路画了一遍，把每个节点的并发特征标出来：哪些是读写均衡的、哪些是写多读少的、哪些是典型的热点操作。这一步看起来不起眼，但它是后面所有方案选择的依据，没有这个业务模型做底，后面全是空中楼阁。

1.2 高并发场景下的四大核心痛点

优化做到后面，我总结出跑腿订单派发系统真正的痛点其实只有四个，别的都只是表象。

第一个是数据库写入瓶颈。订单状态变更在高峰期极其频繁，一个新订单进来要插入订单表、订单快照表、支付流水表，骑手接单又触发多条状态更新记录。单个订单的生命周期内可能产生几十次甚至上百次写操作，在单库单表下，高峰期数据库的行锁竞争和IO压力直接拉满。

第二个是抢单竞态条件。跑腿平台的抢单场景和秒杀非常像：一笔订单推给一批骑手，谁先抢到就是谁的。但和秒杀不同的是，抢单不是只对一个库存字段做扣减，而是要同时校验骑手位置、骑手状态、订单状态、接单距离限制等多个条件。如果这些校验不放在同一个原子操作里，就会出现两个骑手都以为自己抢单成功的“超卖”问题。

第三个是派单风暴。一个订单推送给周围50个骑手，如果高峰期同时有5000个新订单进入派单池，那一瞬间就有25万次推送请求。骑手的App端不断收到订单通知，服务端WebSocket连接和消息推送模块都被打爆。更麻烦的是，骑手端为了抢单会疯狂刷新，请求量又会翻倍。

第四个是地理查询的高频开销。系统需要实时判断“哪个骑手在哪个订单的配送范围内”，以及“用户下单后附近3公里有哪些骑手”。这种计算如果走MySQL的经纬度范围查询，就算加了索引，在高并发下也顶不住。范围扫描加距离排序，数据库CPU很快就飙到100%。

这四个问题不是孤立的，它们互相放大。派单风暴会放大数据库写入压力，抢单竞态会拖慢响应时间，地理查询慢又会加剧整个链路的阻塞。所以优化的思路不能是头痛医头，而要从整体架构上做一次拆解。

2. 订单派发系统的整体架构设计

2.1 技术选型：为什么最终选了这套组合

先交代一下我的技术选型背景：业务是Spring Boot基础框架，MySQL做持久化主库，Redis做缓存和分布式锁，RocketMQ做消息队列，Redis GEO模块承担地理位置计算，ShardingSphere负责分库分表。这套组合没什么炫技的成分，全是当前Java生态里最成熟、最容易招到人维护的组件。

消息队列选择RocketMQ而不是Kafka，是因为跑腿业务对消息可靠性要求更高，而且大量消息是订单事件，需要支持事务消息和延迟消息。比如“订单超过10分钟没有被抢走就自动取消”这种场景，用RocketMQ的延迟消息来做非常顺手，Kafka在这块反而要自己实现。Redis GEO也是我特意选的，Redis 6.2之后GEOSEARCH命令已经很稳定了，比引入ES、MongoDB这类重组件性价比高得多，适合中小规模跑腿平台起步。

很多团队上来就上微服务，把订单、支付、骑手、结算拆成好几个服务，结果高并发问题没解决，先被分布式事务搞死了。我的建议是：在订单派发这个核心链路上，先保持一个单体应用的边界清晰划分，把并发问题用中间件解决，等业务量确实大到需要拆分的时候再拆。我们优化的第一版就是在单体应用里完成的，效果已经很明显，没必要为了架构而架构。

2.2 三个关键设计原则：异步化、削峰填谷、幂等保障

整套架构设计中贯穿了三个原则，这三个原则几乎能解决跑腿业务90%的并发问题。

第一个是异步化。下单请求不直接同步写DB，而是先写一条消息进MQ，由一个专门的消费者异步落库。这样用户端看到的是“下单成功”，而数据库的压力被平滑到消费端慢慢处理。异步化最大的好处是把高毛刺流量变成平稳流量，就像水库蓄水一样，再大的洪峰进来，下游也只是匀速放水。

第二个是削峰填谷。高峰期大量订单同时进来，虽然异步化了，但消费端也可能扛不住，所以消息队列的消费线程数、消费速率都要控制。我这里用到了RocketMQ的消费限流，结合Sentinel对核心接口做兜底限流，超过阈值的请求直接返回“系统繁忙请重试”，宁可牺牲一部分请求也不能让整个系统雪崩。

第三个是幂等保障。这在抢单和支付回调两个环节尤其重要。骑手抢单的请求可能因为网络超时而重试，支付回调也可能重复推送。如果系统在接单和支付状态更新时不保证幂等，那么重试一次就会产生一条重复接单记录，或者把订单状态改错。我的做法是：用Redis的SETNX做一个全局请求ID去重，同时数据库表加唯一约束，双保险。

这三个原则不是选做题，而是必答题。跑腿平台在高峰期如果扛不住，用户第一感知就是下单无响应、骑手不接单，直接导致完单率下降，所以架构上的每一点冗余都是有必要的。

3. 订单派发与抢单机制的核心实现

3.1 订单状态机：让每次状态流转都有据可依

订单状态机的设计是整个派发系统的地基。我先定义了一套枚举，把订单从创建到完成的每个阶段都固定下来，然后明确哪些事件可以触发哪些状态变更，不允许随意跳转。

我定义的核心状态包括：INIT（已创建）、PAID（已支付）、DISPATCHING（派单中）、ACCEPTED（已被接单）、PICKED_UP（已取件）、DELIVERING（配送中）、COMPLETED（已完成）、CANCELLED（已取消）。状态转换由具体事件驱动，比如“骑手接单”事件只能作用在DISPATCHING状态上，如果发现订单已经是ACCEPTED，这个事件就会被拒绝。

java复制public enum OrderState {
    INIT, PAID, DISPATCHING, ACCEPTED, PICKED_UP, DELIVERING, COMPLETED, CANCELLED;

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

    static {
        TRANSITIONS.put(INIT, EnumSet.of(PAID, CANCELLED));
        TRANSITIONS.put(PAID, EnumSet.of(DISPATCHING, CANCELLED));
        TRANSITIONS.put(DISPATCHING, EnumSet.of(ACCEPTED, CANCELLED));
        TRANSITIONS.put(ACCEPTED, EnumSet.of(PICKED_UP, CANCELLED));
        TRANSITIONS.put(PICKED_UP, EnumSet.of(DELIVERING));
        TRANSITIONS.put(DELIVERING, EnumSet.of(COMPLETED, CANCELLED));
    }

    public boolean canTransitionTo(OrderState target) {
        return TRANSITIONS.getOrDefault(this, Collections.emptySet()).contains(target);
    }
}

状态机不是用来炫技的，它最大的价值是让并发场景下的状态更新变得可控。比如用户取消和骑手接单同时到达，先到的人成功变更状态，后到的人因为状态不匹配直接被拒绝，这就从业务逻辑层面规避了一部分并发错误。后面的分布式锁和CAS只是最后一道防线，状态机在前面已经挡掉了大部分脏请求。

实际开发中我还加了一个状态变更记录表，把每次状态变更的发起方、原状态、新状态、时间都记录下来。排查线上问题的时候，这个表能帮大忙，否则一笔订单在哪个环节出了问题，根本无从查起。

3.2 抢单机制：用Redis分布式锁加Lua脚本解决“超卖”

抢单是这个项目里并发性最强的一个环节。直接说结论：纯数据库乐观锁可以解决单点冲突，但扛不住高并发下的重试风暴。我们的方案是Redis分布式锁加Lua脚本，把“校验订单状态+校验骑手条件+更新订单归属”合在一个原子操作里完成。

抢单核心代码的逻辑是这样的：先把订单ID作为锁的key，用SETNX加锁，锁的value设成骑手ID，同时设置过期时间。拿到锁之后，在Lua脚本里完成所有校验和更新，最后释放锁。用Lua脚本是为了保证“检查+更新”的原子性，避免在Java代码里先查再改中间被其他线程插入。

lua复制-- KEYS[1] = order:lock:orderId
-- KEYS[2] = order:basic:orderId
-- ARGV[1] = riderId
-- ARGV[2] = expireTime

if redis.call('exists', KEYS[2]) == 0 then
    return 0
end

local orderState = redis.call('hget', KEYS[2], 'state')
if orderState ~= 'DISPATCHING' then
    return 0
end

if redis.call('exists', KEYS[1]) == 1 then
    return 0
end

redis.call('set', KEYS[1], ARGV[1], 'EX', ARGV[2])
redis.call('hset', KEYS[2], 'state', 'ACCEPTED')
redis.call('hset', KEYS[2], 'riderId', ARGV[1])
return 1

这个方案做出来后，抢单响应时间从原来的平均100ms降到了30ms以内，而且彻底杜绝了两个骑手同时抢到同一单的问题。需要注意几个坑：锁的过期时间不能设太短，否则订单处理到一半锁就没了；但也不能太长，否则骑手抢到锁之后处理失败，订单会被锁死很长时间。我这边设置的是10秒，然后在业务处理完成后主动释放锁。

还有一个细节：释放锁的时候必须用Lua脚本比较value再删除，不能用简单的DEL，否则可能出现“我的锁被别人释放”的问题。这个坑在并发场景下非常经典，很多团队都是在这里翻的车。

3.3 骑手位置与派单范围：Redis GEO的落地实践

之前跑腿订单推送骑手的逻辑，是先查数据库里离取件点3公里内的在线骑手，然后按照距离排序，取出前50个推送。上线初期单量少没问题，但一到高峰期，这个查询就把数据库CPU吃满了。我后来把骑手实时位置迁移到了Redis GEO。

每条骑手上报的GPS信息，直接用GEOADD写入Redis，key按城市拆分成多个，避免单个key数据量过大。查询附近骑手就一行GEOSEARCH。这个方案的性能提升是数量级的，一次3公里范围的骑手查询只要几毫秒，而且在Redis集群下可以水平扩展。

java复制// 骑手上报位置
stringRedisTemplate.opsForGeo().add("rider:geo:beijing", 
        new Point(longitude, latitude), riderId.toString());

// 查询取件点3公里内的骑手
GeoResults<RedisGeoCommands.GeoLocation<String>> results = 
        stringRedisTemplate.opsForGeo()
        .search("rider:geo:beijing",
                new Circle(new Point(orderLon, orderLat), 
                           new Distance(3, RedisGeoCommands.DistanceUnit.KILOMETERS)));

但这里有一个坑：Redis GEO只存位置，不存骑手状态。一个骑手可能已经处于配送中、没空接新单，但他的位置还在GEO里。所以查询到候选骑手之后，还必须过滤一遍骑手状态。我本来想把这步放在Java业务层做，后来发现高峰期这批查询也占了不小的开销，干脆把骑手状态也缓存到Redis，用Hash结构存骑手ID到状态的映射，在GEO查询后直接用管道批量拉取状态，减少一次网络往返。

3.4 派单通知的推送策略：如何防止“派单风暴”

一开始我们把一笔订单推送给50个骑手，是同时全部推送的，结果每一次高峰期，消息推送服务都会被打垮。后来我换成了分批推送策略，不再一口气把50个骑手全部推完，而是先推最近的20个，间隔200ms之后如果订单还没被抢，再补推下一批。如果超过2分钟还没有骑手接单，系统自动触发加价策略，同时扩大推送半径。

这个策略背后的逻辑是：离得最近的骑手最愿意接单，如果这批人不接，说明订单本身吸引力不够，继续推给更远的骑手意义不大，不如直接加小费重新洗牌。分批推送还有一个额外的好处，就是避免了50个骑手同时在App端抢单导致的高并发冲突，前端感知上更平滑。

推送通道我们用的是WebSocket长连接，每个骑手App和服务器维持一条长连接。高并发下长连接的数量非常多，我用Netty做了一层推送网关，把业务服务和推送连接解耦。业务服务只负责把推送指令写入MQ，推送网关消费消息后发到具体的连接上。这样即使推送瞬间量很大，也不会阻塞订单主流程。

3.5 订单详情聚合：用CompletableFuture把串行改成并发

配送到后面阶段，骑手端打开订单详情页，要同时展示订单基本信息、骑手位置、配送轨迹、预估时间、费用明细、用户备注等数据。刚开始这些数据是接口里一步步查的，一个详情接口平均耗时200多毫秒，高峰期大量查询打到数据库，明显感觉到卡顿。

我重构的时候把详情聚合改成了CompletableFuture异步编排，把多个无关的查询并行执行，最后用allOf汇总。订单基本信息从缓存拿，配送轨迹走ES，费用明细查MySQL，位置信息从Redis GEO拿，这些操作互相没有依赖，完全可以在不同线程里同时跑。

java复制CompletableFuture<OrderBasicVO> basicFuture = 
        CompletableFuture.supplyAsync(() -> getOrderBasic(orderId), executor);
CompletableFuture<List<TrackPointVO>> trackFuture = 
        CompletableFuture.supplyAsync(() -> getTrackList(orderId), executor);
CompletableFuture<FeeVO> feeFuture = 
        CompletableFuture.supplyAsync(() -> getFeeDetail(orderId), executor);

CompletableFuture.allOf(basicFuture, trackFuture, feeFuture).join();

OrderDetailVO vo = new OrderDetailVO();
vo.setBasic(basicFuture.get());
vo.setTracks(trackFuture.get());
vo.setFee(feeFuture.get());

重构后接口耗时降到了80毫秒以内，而且因为用了一个独立的线程池，并没有把Tomcat的工作线程池占满。这里我必须要提醒一下：CompletableFuture默认用的是ForkJoinPool.commonPool，在高并发Web服务里一定不要直接用默认的，要自定义线程池，否则长任务会把通用线程池饿死，影响其他业务。

4. 数据存储与消息队列的高并发治理

4.1 订单库的分库分表策略：不是所有表都需要拆

很多人一听到高并发就想分库分表，但我的经验是：拆表要谨慎，拆对了才有价值。我们的订单表在单量达到一定量级后确实需要拆，但拆的方式很讲究。订单表的查询场景主要有两类：用户查自己的订单、骑手查自己的接单记录。这两类查询的维度不一样，一个按用户ID查，一个按骑手ID查。

我最终选择了按照订单ID做哈希分片，分成16个库128张表。订单ID用雪花算法生成，带上了时间戳和机器ID，保证全局唯一且趋势递增。用户查订单的时候，先把用户ID和订单ID做一个绑定关系存储（用户ID -> 订单ID列表），查询时先查绑定关系拿到订单ID，再定位到具体的分片。

骑手查待配送订单的情况比较特殊，它不完全依赖订单表。骑手App首页显示的“待接单”“配送中”这些列表，直接从Redis和ES里取，而不是查订单库。只有点进详情的时候才按订单ID查分片表。这样一来，订单库面对的主要是点查和按订单ID的范围查，分片后的性能非常稳定。

分库分表我用的是ShardingSphere，配置相对简单，而且和Spring Boot集成很顺滑。要注意一点：分片键必须出现在SQL的WHERE条件里，否则会全路由扫描所有分片，查询性能急剧下降。这个坑我们在上线初期踩过一次，后来在拦截器里加了强制校验，发现没有分片键的SQL直接报错，宁可报错也不能拖垮库。

4.2 多级缓存与一致性：订单状态不读库也能快

订单详情的查询频率远高于写频率，所以非常适合加缓存。我设计的是两级缓存：本地Caffeine做一级缓存，Redis做二级缓存。热点订单的详情直接在本地缓存取，取不到再去Redis，Redis再取不到才查数据库。这一层优化之后，订单详情接口的QPS支撑能力提升了三到四倍。

缓存的一致性是最头疼的问题。订单状态一旦变化，必须通知其他服务缓存失效。我的方案是：所有订单状态变更都通过RocketMQ发一条状态变更消息，消费者收到消息后删除Redis缓存并更新本地缓存。为什么不直接更新缓存而是删缓存？因为更新缓存容易出现并发问题——两个线程同时写缓存，后写的可能覆盖先写的正确数据，而删除缓存之后，下一次查询会回源数据库，能拿到最新值，更安全。

缓存穿透也要防范。如果一个订单ID被恶意请求，而数据库里根本没有这个订单，那每次请求都会穿透到DB。我的做法是：查询结果为空时也在Redis里缓存一个空值，设置较短的过期时间，比如60秒。这样可以挡住大量无效请求打到数据库。

4.3 消息队列削峰与最终一致性：下单高峰不再打垮数据库

下单高峰期，如果10000个用户同时提交订单，直接全量写MySQL，数据库十有八九要出问题。我的方案是：下单请求进入接口后，先做一些基础校验，然后直接返回“下单成功”，同时把订单数据发到RocketMQ，由消费者异步写入订单表。用户看到的响应时间从原来的200ms降到了50ms，数据库压力也平缓了很多。

这里要注意消息的可靠性。RocketMQ默认的同步发送方式，在极端情况下可能丢失消息，所以我在生产端开启了事务消息。具体流程是：先写半消息，然后执行本地事务（生成订单号并落一条预订单状态），事务提交后再commit消息。消费者只有在收到commit后的消息才会真正落库。这套机制保证了“用户提交下单请求”和“订单数据写入MQ”两者的最终一致性。

消费端也做了幂等处理，我用订单ID作为去重键，消费时先查Redis里有没有这个订单ID的处理记录，没有才执行落库。消息队列本身at-least-once的特性会导致重复消费，如果不做幂等，一个订单就会被插入两次。

5. 上线运行中的常见问题与排查实录

5.1 抢单风暴：Redis锁没顶住，数据库连接被瞬间打满

上线后第一次高峰期，我就遇到了抢单风暴。现象是数据库连接池瞬间被占满，大量请求超时。排查日志发现，虽然抢单逻辑加了Redis锁，但有一个问题：当锁获取失败时，代码里默认的重试逻辑是“立刻重试第1次、等待100ms重试第2次”，这个等待时间在高并发下完全是不够的，导致大量线程阻塞在抢锁等待上。

解决方案是引入退避重试策略，抢锁失败后随机等待200-500ms再重试，最多重试3次，3次都失败就把这笔订单标记为“下次派单优先”，不再让请求无限重试。另外我还给抢单接口单独配置了一个线程池，和服务主线程池隔离，防止抢单的重试请求把正常业务拖垮。

5.2 订单状态不一致：Redis缓存和数据库数据漂移

运营反馈说，有个别订单骑手已经接单了，但用户端一直显示“等待接单”。定位后发现这是缓存一致性问题：骑手接单之后，状态更新先写数据库，然后发消息删Redis缓存。但这个消息在极端情况下消费失败，缓存一直没删除，用户端就一直读取旧状态。

我后来做了修复：状态更新后不仅发MQ，同时直连Redis删一次缓存，MQ的删除作为兜底。另外缓存过期时间从30分钟缩短到5分钟，即使删除操作完全失败，缓存也会在短时间内过期，重新回源数据库。双保险加上短过期时间，这个现象再没出现过。

5.3 骑手定位上报导致写放大：GEO写入阻塞

骑手App默认每2秒上报一次定位，高峰期上线的骑手一多，Redis的GEO写入量非常大。有一段时间我发现Redis主节点的CPU持续很高，排查发现光GEOADD操作每秒就有几万次。这引出了另一个问题：GEO写入和订单数据的Redis操作混在同一个集群，互相影响。

我的处理方案有两步。第一，把骑手定位的GEO key单独拆到独立的Redis集群，和订单业务数据物理隔离。第二，调整上报策略，骑手静止时每10秒上报一次，移动时才2秒上报一次，同时服务端做了批量合并处理，同一骑手在1秒内的多次上报只保留最后一次。改造后Redis负载直接降了一半。

5.4 锁超时引发的订单丢失：长业务导致锁提前失效

有一次压测发现，有订单在骑手抢单后状态没有更新，排查下来是抢单业务处理时间超过了锁的过期时间。当时锁设置了5秒过期，但处理抢单时逻辑里有几个远程调用，最慢的情况超过了5秒，锁自动释放后其他骑手又抢了这单，造成数据错乱。

解决方法是双管齐下。一是把锁过期时间从5秒调整到10秒，同时把业务里的远程调用异步化，抢单核心流程只做本地操作和Redis操作，前端展示需要的数据等抢单成功后异步补齐；二是引入看门狗机制，在锁快要过期但业务还在执行时，自动续期。这个机制类似Redisson的watch dog，但我们是自己实现的一个简化版。

5.5 JVM内存溢出：推送队列把堆挤爆了

有一版改完推送模块后，上线没多久就报出了OutOfMemoryError，日志里的关键词是Java heap space。用堆转储工具分析后，发现问题出在推送队列上：推送网关用一个内存队列暂存待发送的消息，但消费者发送速度跟不上生产者写入速度，队列越积越多，最后把堆撑爆。

修复方案很简单也很讽刺：不是去优化GC参数，而是给队列加了一个上限，超过上限后新消息直接丢弃并记录日志，同时增加告警。这个思路其实就是缓冲区背压思想——生产者不能无限制往队列里写，必须感知消费端的处理能力。后面我把推送队列改成了有界队列，满了之后订单派单组件会感知到并自动降级为更小范围的骑手推送，优先保证系统不崩溃。

6. 面试视角与优化经验复盘

6.1 面试官视角：这个项目怎么讲才能讲出深度

很多Java开发者在面试时讲高并发项目，容易变成罗列技术名词、背八股文——Redis、MQ、分布式锁、分库分表全说一遍，但面试官一问“为什么这里用Redis锁而不是Zookeeper锁”“你的消息队列怎么保证不丢消息”就答不上来。其实面试官最想听的不是你用了什么，而是你在做技术选型和方案落地时，有没有自己的判断依据。

我在复盘这个项目时，把每个技术点都重新梳理出了“为什么”这层逻辑。比如分布式锁，我不只讲SETNX，还会补充为什么选择Redis而不是数据库乐观锁（因为数据库锁在冲突率高时重试成本太高），以及为什么不用Zookeeper锁（因为抢单场景对性能敏感，ZK的会话创建和监听机制在极致并发下延迟偏高）。再比如分库分表，我会讲清楚为什么要按订单ID哈希而不是按用户ID或时间，因为按时间分片会形成明显的热节点——所有最新订单都写同一个分片，完全失去分库的意义。

准备面试的话，我强烈建议把代码里的判断依据写进项目文档里，而不是只写下最终方案。描述项目时，要有一条清晰的演进线：最初是什么样、遇到了什么问题、为什么换方案、换完后效果如何、有没有引入新问题。这样讲出来的项目才是立体的，比背一堆名词有说服力得多。

6.2 优化顺序的性价比思考：先做对的事，再做炫的事

做过一轮完整优化之后，我最大的体会是：高并发优化是有顺序的，不是把最牛的技术堆上去就行。我的建议顺序是：先解决业务逻辑层的并发缺陷——状态机、幂等、分布式锁；再做存储层的优化——缓存、分库分表；最后才是中间件的架构升级——引入更重的消息队列、独立的推送网关。

为什么是这个顺序？因为前两层的问题不解决，后面堆再多中间件也只是在延迟崩溃。比如订单状态机不完善，即使Redis性能再高，脏数据依旧会产生，系统只是更快地产生脏数据而已。反过来，如果业务逻辑已经足够健壮，那么一个Redis加一个RocketMQ基本就能支撑大部分跑腿平台的峰值流量，根本不需要一开始就上一个几十节点的微服务集群。

还有一个性价比的观点是：不要过度设计。很多优化方案在业务量只有几万单的时候完全没必要，强行上分布式事务、上多级缓存，反而把系统复杂度推高，出问题的概率更大。我建议用一个简单的压测工具先摸底，看看当前系统瓶颈到底在哪，缺的是CPU还是IO还是连接数，然后针对性优化，这样才不会花了大价钱做了一堆无用功。

最后再分享一个我自己踩出来的经验：任何高并发改动都一定要带着监控和压测上线。我们每一轮优化都配了对应的监控面板，包括Redis命中率、消息消费积压量、数据库连接池水位、接口RT和错误率。没有这些数据，你根本不知道你的优化到底有没有效果，也不知道下一次系统会从哪里崩。这个项目的成功，一半靠代码，一半靠的是这些看不见的监控数据。