同城配送平台有哪些核心源码避坑指南
面试被问“同城配送系统怎么保证不超卖”，你支支吾吾答不上来？别慌，这正是你离大厂 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 (fmtsync
)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 的文档，前端应该在用户点击“下单”后立即禁用按钮，并设置超时重试机制，避免用户疯狂点击导致后端收到大量重复请求。避坑总结：别迷信单机锁：分布式环境下，Redis Lua 是标配。
别忽略幂等性：网络抖动必然导致重复请求，没有幂等设计的系统必崩。
别只看代码不看监控：源码写得再完美，没有 APM 监控（如 SkyWalking, Prometheus）就是盲人摸象。你在项目里踩过这个坑吗？是库存超卖了，还是重复扣费了？评论区聊聊，看看谁踩的坑更深。 同城配送平台有哪些核心源码避坑指南
同城配送平台有哪些核心源码避坑指南
面试被问“同城配送系统怎么保证不超卖”，你支支吾吾答不上来？别慌，这正是你离大厂 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 (fmtsync
)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 的文档，前端应该在用户点击“下单”后立即禁用按钮，并设置超时重试机制，避免用户疯狂点击导致后端收到大量重复请求。避坑总结：别迷信单机锁：分布式环境下，Redis Lua 是标配。
别忽略幂等性：网络抖动必然导致重复请求，没有幂等设计的系统必崩。
别只看代码不看监控：源码写得再完美，没有 APM 监控（如 SkyWalking, Prometheus）就是盲人摸象。你在项目里踩过这个坑吗？是库存超卖了，还是重复扣费了？评论区聊聊，看看谁踩的坑更深。