同城配送平台有哪些核心源码避坑指南

面试被问“同城配送系统怎么保证不超卖”，你支支吾吾答不上来？别慌，这正是你离大厂 Offer 最近的时候。

很多后端开发在面试时，喜欢把同城配送、外卖系统挂在嘴边，但真问到底层实现细节，往往只能背八股文。今天这篇避坑指南，我们直接扒开主流开源配送系统的底层逻辑，不玩虚的，只讲源码里那些能救命的设计细节。

入口定位：从 API 网关看业务分流

在拆解核心源码前，你得先搞清楚请求是怎么进来的。以主流的 Spring Cloud 微服务架构为例，同城配送平台的入口通常不是直接打到业务层，而是经过 API Gateway。

很多初学者容易忽略网关层的限流与熔断配置。在高峰期（如中午 12 点），订单量呈指数级增长，如果网关没做好流量整形，下游的库存服务瞬间就会被打挂。

看这段典型的 Gateway 配置源码，注意 rateLimiter 策略的粒度：

// 伪代码示例：Spring Cloud Gateway 动态路由配置片段
RouteLocator routeLocator(RouteLocatorBuilder builder) {return builder.routes().route("delivery-order", r -> r.path("/api/v1/order/**")// 关键点：基于 IP + 用户 ID 进行滑动窗口限流.filters(f -> f.requestRateLimiter(c -> c.setRateLimiter(redisRateLimiter).setReplenishRate(10) // 每秒补充令牌 10 个.setBurstCapacity(50) // 突发容量 50 个)).uri("lb://delivery-order-service")).build();
}

逐行解析：

path("/api/v1/order/**")：匹配所有下单相关的接口路径。
setReplenishRate(10)：这是令牌桶算法的核心参数。设定每秒补充 10 个令牌，意味着平均 QPS 限制在 10 以内。对于非核心用户，这个值通常设得很低，防止恶意刷单。
setBurstCapacity(50)：允许瞬间突发 50 个请求。这对应了用户“手抖”连点或者网络重试的场景。如果这个值设为 1，用户体验会极差；如果设为 1000，则失去保护意义。

避坑点： 很多开发者在本地测试时，直接改大 BurstCapacity 来通过测试，上线后却忘了改回来。记住，生产环境的限流阈值必须依据监控数据动态调整，而不是拍脑袋决定。

核心片段：库存扣减的“防重”与“一致性”

同城配送最核心的痛点是什么？库存一致性。用户 A 下单了最后 1 份蛋糕，用户 B 几乎同时下单，系统必须保证只有一个人成功。

大多数系统采用 Redis + MySQL 的双写模式，但真正的坑在于并发控制。直接看源码，这是基于 Redis Lua 脚本的原子性扣减逻辑：

-- Redis Lua 脚本：原子性库存检查与扣减
-- KEYS[1]: 库存 Key (例如 stock:cake:001)
-- KEYS[2]: 订单幂等 Key (例如 order:lock:userId:orderId)
-- ARGV[1]: 需要扣减的数量 (1)local stock_key = KEYS[1]
local lock_key = KEYS[2]
local deduct_num = tonumber(ARGV[1])-- 1. 检查库存是否存在
local stock = redis.call('GET', stock_key)
if stock == false thenreturn -1 -- 商品不存在
end-- 2. 检查库存是否充足
if tonumber(stock) < deduct_num thenreturn -2 -- 库存不足
end-- 3. 尝试获取分布式锁，防止同一用户重复下单
-- 使用 SETNX 命令，设置 5 秒过期，防止死锁
local lock_result = redis.call('SET', lock_key, '1', 'NX', 'EX', 5)
if lock_result == 0 thenreturn -3 -- 用户正在处理中，请勿重复操作
end-- 4. 执行扣减
redis.call('DECRBY', stock_key, deduct_num)-- 5. 返回成功状态及剩余库存
return tonumber(redis.call('GET', stock_key))

逐行深度解读：

if stock == false：注意这里判断的是 false 而不是 nil，Redis Lua 中 Key 不存在返回的是 false。这是一个常见的语法陷阱，写错会导致逻辑判断失效。
SET ... NX ... EX 5：这是 Redis 实现分布式锁的标准姿势。NX 保证只有当 Key 不存在时才能设置成功，EX 5 设置 5 秒自动过期。为什么要 5 秒？ 因为业务逻辑处理时间通常远小于 5 秒，如果用户宕机，锁会在 5 秒后自动释放，避免永久死锁。
DECRBY：原子性减操作。Lua 脚本在 Redis 中是原子执行的，这意味着从“检查库存”到“扣减库存”中间不会被其他线程插入，彻底解决了超卖问题。

避坑点： 很多新手会在 Java 代码里先 GET 检查库存，再 DECR 扣减。这在单机环境下可能没问题，但在高并发下，两个线程同时 GET 到库存为 1，然后同时 DECR，结果库存变成 -1。永远不要在非原子操作中间穿插业务判断。

设计思想：为什么不用数据库乐观锁？

你可能会问：既然 Redis 这么麻烦，为什么不在 MySQL 里用 UPDATE stock SET count = count - 1 WHERE id = ? AND count > 0 这种乐观锁？

答案在于性能瓶颈与数据一致性边界。

MySQL 的行锁竞争：在高并发场景下，针对同一热门商品（如爆款蛋糕），大量的 UPDATE 语句会持有行锁。如果事务过长（比如还要写订单表、扣减积分表），锁持有时间变长，后续请求全部阻塞，导致数据库连接池耗尽。
Redis 的吞吐能力：Redis 是内存数据库，单线程处理 Lua 脚本，吞吐量可达十万级 QPS。将“检查+扣减”这一高频操作前置到 Redis，可以拦截 90% 以上的无效请求（库存不足或重复下单），只有真正通过 Redis 校验的请求才会进入 MySQL 事务。

设计精髓： 利用 Redis 做**“快进快出”的流量闸门，利用 MySQL 做“最终一致”**的数据落地。这种分层架构是同城配送系统高可用的基石。

手写简化版：Go 语言实现核心逻辑

为了让你更直观地理解，我们用 Go 语言写一个简化的内存版逻辑（生产环境请用 Redis）：

package mainimport ("fmt""sync"
)type DeliveryService struct {mu     sync.Mutexstock  map[string]intorders map[string]bool // 模拟幂等性
}func NewDeliveryService() *DeliveryService {return &DeliveryService{stock:  make(map[string]int),orders: make(map[string]bool),}
}func (s *DeliveryService) InitStock(productID string, count int) {s.mu.Lock()defer s.mu.Unlock()s.stock[productID] = count
}func (s *DeliveryService) PlaceOrder(userID, productID, orderID string) (bool, string) {s.mu.Lock()defer s.mu.Unlock()// 1. 幂等性检查：防止同一订单重复提交if s.orders[orderID] {return false, "Order already exists"}// 2. 库存检查currentStock, exists := s.stock[productID]if !exists || currentStock < 1 {return false, "Out of stock"}// 3. 扣减库存s.stock[productID] = currentStock - 1// 4. 标记订单已处理s.orders[orderID] = truereturn true, "Success"
}func main() {svc := NewDeliveryService()svc.InitStock("cake_001", 1)// 模拟并发下单var wg sync.WaitGroupfor i := 0; i < 10; i++ {wg.Add(1)go func(id int) {defer wg.Done()ok, msg := svc.PlaceOrder("user_1", "cake_001", fmt.Sprintf("order_%d", id))if ok {fmt.Printf("Order %d: %s\n", id, msg)} else {fmt.Printf("Order %d Failed: %s\n", id, msg)}}(i)}wg.Wait()
}

代码解析：

sync.Mutex：Go 的互斥锁，保证了 PlaceOrder 方法内部的临界区安全。
s.orders[orderID]：这是一个简单的幂等性检查。在实际系统中，这个检查通常放在 Redis 中，因为 MySQL 查询太慢。
注意：这个 Go 示例仅用于理解逻辑，生产环境严禁使用内存 Map 存储库存，必须使用 Redis 集群。

应用场景与面试高频追问

理解了源码和逻辑后，面试中可能会遇到以下追问：

如果 Redis 宕机了怎么办？
- 答：主从架构 + 哨兵机制自动切换。极端情况下，可以降级为直接查 MySQL 乐观锁，虽然性能下降，但保证业务可用。同时，监控报警会立即通知运维介入。
如何防止“先扣库存后支付超时”导致的库存回滚？
- 答：引入延迟队列。下单时扣减 Redis 库存，发送一条延迟 15 分钟的消息到 RabbitMQ/RocketMQ。如果 15 分钟内用户未支付，消费消息时执行库存回滚（INCRBY）。如果用户已支付，则取消该回滚任务。
MDN Web Docs 对前端交互的建议
- 虽然我们是后端，但前端体验直接影响后端压力。参考 MDN Web Docs 关于 fetch 和 AbortController 的文档，前端应该在用户点击“下单”后立即禁用按钮，并设置超时重试机制，避免用户疯狂点击导致后端收到大量重复请求。