订单洪峰在午间11点准时抵达——这是平易客配送系统每天都要面对的常态。作为一款服务于外卖系统、微信外卖订餐小程序及跑腿系统的底层引擎，高并发架构的设计质量直接决定了商户能否在高峰期稳住每一笔订单。我们团队在过去几年里，经历了多次流量从百级到万级的跃升，也踩过不少坑。以下是我们沉淀下来的几个核心要点。

弹性伸缩与无状态化设计

传统单体架构在流量突增时，往往只能纵向扩容，成本高且响应慢。平易客配送系统从一开始就采用Kubernetes+容器化部署，核心服务全部实现无状态化。这意味着当外卖系统在午间涌入数千笔并发订单时，集群可以自动在30秒内扩展出10个pod来分担压力。我们曾在一次促销活动中见证过系统在3分钟内扛住每秒1200次请求的冲击，而CPU负载始终控制在70%以下。关键点在于：会话数据必须外迁到Redis集群，不能留在本地内存，否则扩容等于白费。

读写分离与缓存策略的实战取舍

对于微信外卖订餐小程序这类前端交互密集的场景，数据库往往是最先崩溃的环节。平易客的做法是：读操作全部走Redis缓存，写操作则通过消息队列异步落库。比如用户查询附近店铺列表，我们预加载了经纬度索引到缓存层，查询延迟从200ms降至8ms。但有一个容易被忽略的细节：缓存失效时的“惊群效应”——我们通过互斥锁+渐进式过期来规避，避免一瞬间所有请求都穿透到数据库。跑腿系统的实时定位数据同样适用此策略，高峰期点位更新频次可达每秒5000次，缓存层扛下了90%的读取量。

• 缓存穿透：布隆过滤器拦截无效key，比如恶意请求的非法ID
• 缓存雪崩：基础数据设置随机过期时间，打散失效窗口
• 数据库连接池：HikariCP配置最小10个、最大50个连接，避免资源争抢

异步架构与削峰填谷

订单生成、支付回调、配送分单这三个环节，在平易客系统中是完全解耦的。用户点击“下单”后，请求直接进入Kafka队列，前端立即返回“订单提交成功”。后台的订单处理、库存校验、骑手调度则各自消费队列消息。这种设计让外卖系统在爆单时不会因为任何一个环节的阻塞而拖垮整体。去年双十二期间，平易客跑腿系统的单日订单量突破50万笔，队列积压最多时达到8万条，但通过调整消费者线程数（从默认10调整到25），积压在15分钟内全部消化，用户端无感知。

超卖与库存一致性的工程解法

高并发下最致命的问题不是慢，而是数据不一致。平易客配送系统在库存扣减上采用Redis+Lua脚本的原子操作，将“预扣库存”和“实际扣减”分两步走。比如微信外卖订餐小程序中的“秒杀”活动，用户点击购买时先通过Redis预扣，如果成功则生成待支付订单；若15分钟内未支付，通过定时任务回滚库存。这避免了数据库行锁导致的并发瓶颈。实测数据：在100并发下，传统数据库扣库存的TPS约为300，而Lua脚本方案达到4500，提升了15倍。

最后一点值得强调：高并发架构没有银弹。平易客团队在每次大促后都会复盘全链路日志，比如我们发现Nginx的worker_connections默认值在单机3000并发时会出现丢包，调整为65535后问题解决。架构是活的，需要持续迭代。如果你正在搭建外卖系统或跑腿系统，不妨先从压测你的缓存层和队列吞吐量开始——这两个环节往往是木桶的最短板。