外卖系统后台架构设计与高并发实战

1. 项目概述从零搭建外卖系统后台去年接手公司外卖平台重构项目时我深刻体会到后台系统才是支撑业务运转的隐形引擎。这个被我们内部称为苍穹外卖的项目在第二天就需要完成用户端与商家端的关键对接。不同于前端界面的直观可见后台系统如同城市的地下管网需要精密设计每个数据流转环节。2. 核心模块设计解析2.1 分布式登录架构设计采用JWTRedis双校验机制时遇到过单点登录失效的坑。我们的解决方案是生成Token时加入设备指纹前端传入的deviceId经过SHA256加密Redis存储结构采用hash类型key: login:user:{userId} field: {deviceId} value: token重要提示务必设置Redis键的自动过期时间建议比JWT过期时间多30秒避免边缘情况下的校验失败。2.2 订单状态机实现状态流转是外卖系统的核心难点我们最终采用状态模式事件总线的混合方案当前状态允许操作目标状态触发条件待支付取消订单已取消用户操作待支付支付成功待接单支付回调待接单商家接单已接单商家操作已接单开始配送配送中骑手操作实际开发中发现骑手端和商家端的状态同步存在延迟问题最终通过以下优化解决使用WebSocket实现状态变更推送增加状态变更MQ消息的消费重试机制数据库增加乐观锁版本控制3. 高并发场景应对方案3.1 库存扣减的三种方案对比在高峰期秒杀活动中我们实测了不同方案的性能表现方案QPS优点缺点数据库行锁1200实现简单连接池易耗尽Redis原子操作8500性能优异需处理缓存一致性RedisLua脚本9200原子性最佳调试复杂最终选择方案三关键Lua脚本如下local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then redis.call(DECR, KEYS[1]) return 1 end return 03.2 分布式ID生成策略雪花算法在实际使用中遇到时间回拨问题我们的改进方案增加Zookeeper协调节点编号分配检测到时间回拨时自动切换备用IDC时钟源本地缓存最近100ms生成的ID作为缓冲核心参数配置示例// 机器ID占5位最大31 // 序列号占12位最大4095 long workerId zkClient.getWorkerId() 0x1F; long sequence (System.currentTimeMillis() - twepoch) 22 | (workerId 17) | (sequenceCounter 0xFFF);4. 实战中的典型问题排查4.1 支付回调丢失事件某次大促期间出现0.3%的支付成功但订单未更新的情况排查过程日志分析发现回调接口平均响应时间达1.2s超过支付平台超时设置线程池监控显示核心线程全被慢SQL阻塞最终定位到商户查询接口未走索引解决方案为merchant_id字段添加联合索引支付回调改为异步处理结果轮询增加补偿任务扫描支付状态4.2 地理围栏计算优化原Haversine公式计算配送范围时CPU负载过高# 优化前每单计算耗时15ms distance 2 * 6371 * asin(sqrt(a)) # 优化后使用平面近似缓存耗时0.3ms if abs(lat1-lat2) 0.02: # 约2公里范围内 distance 111 * sqrt((lat1-lat2)**2 (cos(lat1)*(lng1-lng2))**2)配合Redis GEOADD存储商家坐标查询性能提升50倍。5. 监控体系搭建要点5.1 关键指标埋点设计我们定义的黄金指标包含订单创建成功率99.5%支付回调平均延迟500ms库存操作异常率0.1%Prometheus配置示例- pattern: order/create name: order_create_total labels: status: $1 # success/fail source: $2 # app/web5.2 日志规范实践采用结构化日志后故障定位时间缩短70%。关键字段包括{ traceId: a1b2c3d4, spanId: e5f6g7h8, userId: 12345, action: order.create, params: { shopId: 678, amount: 38.5 } }日志收集方案对比FilebeatELK适合中小规模FluentdKafkaClickHouse支持PB级数据6. 持续交付流水线6.1 多环境配置管理通过Spring Cloud Config实现配置中心化特别注意数据库密码等敏感信息使用Vault加密环境变量优先级高于配置中心配置变更通过Webhook触发自动重启6.2 自动化测试策略我们的测试金字塔结构单元测试覆盖率80%核心业务100%集成测试重点验证支付流程端到端测试仅覆盖主路径使用Testcontainers进行数据库集成测试Container static PostgreSQLContainer? postgres new PostgreSQLContainer(postgres:13); Test void shouldCreateOrder() { // 使用真实数据库测试 orderRepository.save(testOrder); assertThat(orderService.getById(testOrder.getId())).isNotNull(); }这套系统经过双11级别流量验证峰值QPS达到12万期间核心服务零宕机。最大的收获是分布式系统要把故障当作常态来设计每个环节都需要考虑降级方案。比如当Redis不可用时我们自动降级到本地缓存数据库校验的模式虽然会有短暂的数据不一致但保证了核心流程可用。