校园外卖高峰怎么扛：订单状态机、楼栋履约与腾讯云上的削峰拼装

问题从哪来：校园外卖把峰值与履约约束拧在一起

同城外卖可以把「地址」当成道路坐标，「运力」当成城市骑手池。校园外卖不是缩小版同城：围墙与门禁、楼栋驿站取餐、午晚高峰脉冲极陡、学期制带来季节性流量、用户高度同质。失败形态高度集中——高峰崩、楼栋乱、售后吵——背后往往是同一类工程缺口：订单状态机含糊、库存没有预扣、接入层无限流、非关键路径与下单同事务、运单事件与柜机/驿站没有统一契约。

本文按云上工程边界拆：领域分层与腾讯云组件选型、订单与运单状态机、表结构草图、REST/事件接口、午高峰时序、库存预扣幂等、楼栋履约、失败模式与观测。不讨论首页怎么好看，也不讨论采购或源码交付；只讨论系统怎么在整点十五分钟里算得清、削得住、送到站。

校园外卖高峰：订单状态与云上边界

领域分层：先画边界，再点名组件

校园外卖建议按域切开，而不是按「小程序页面」堆接口。一层逻辑对应一类扩展与一类故障面：

小程序或 H5 前端可用 CloudBase 静态托管与云开发能力做轻量落地；核心交易与履约建议放到云托管（容器）以便水平扩展下单/接单接口。寒暑假缩容、开学与考试周扩容，按校历做弹性，而不是按「感觉」调副本数。订单热点表与历史归档分库或分表，避免学期末分析拖垮在线库。

硬约束三条：

1. 下单主路径同步、通知与积分异步——不要把订阅消息写进支付回调的同一同步链。
2. 库存用「可售 / 预扣 / 实扣」三分账——单一整数计数器在午高峰必超卖。
3. 履约方式在下单时锁定——驿站自取、寝室直送、到店自取可并存，但一单一模式，状态机才写得清。

订单与运单状态机：先画转移，再写接口

校园外卖的核心对象是「订单实例 + 运单实例」，不是「商家工作台截图」。订单状态建议至少覆盖：

运单（fulfillment_ticket）建议独立状态：DISPATCHED → PICKED → IN_TRANSIT → AT_STATION → VERIFIED / EXCEPTION。订单与运单用事件对齐，避免骑手端直接 UPDATE orders SET status。

两条硬约束：

1. 转移必须带原因码与操作者（学生取消、商家拒单、支付超时、站点管理员强制核销）。裸改状态字段无法复盘社群里的「我明明付了」。
2. 到站与核销必须幂等。弱网下骑手重复点「已到站」、学生重复出示取餐码非常常见；同一 order_id + idempotency_key 重放应返回同一业务回执。

ARRIVED_STATION 与 TIMEOUT_UNPICKED 是校园特有、最容易被省略的中间态：若直接从 PICKED_UP 跳到 COMPLETED，未取餐、错拿餐、柜格绑定失败都只能塞进备注，售后无法自动化。

表结构草图（可单体，边界按域切开）

早期可单体部署，表与接口按域切开，后续拆服务少搬家。

订单 campus_order

• id, campus_id, user_id, stall_id
• fulfill_mode（STATION / DORM / SELF_PICKUP）
• building_id, station_id, dorm_text（直送时；优先结构化楼栋单元）
• status, pay_amount, paid_at
• idempotency_key（客户端下单键）
• version（乐观锁）

订单行 campus_order_item

• order_id, sku_id, qty, price_snapshot, period_tag（早餐/午餐/夜宵）

库存账 sku_stock

• sku_id, campus_id, period_tag, biz_date
• available, reserved, sold
• version

「可售 / 预扣 / 实扣」：下单事务内 available--、reserved++；支付成功转 reserved→sold；关单/退款释放预扣。超卖事故大多来自「只减一个整数、无预留、无业务日维度」——校园菜单按餐段与自然日切库存，切日要用业务时区（UTC+8），不要用服务器默认 UTC。

运单 fulfillment_ticket

• id, order_id, rider_id, station_id
• status, pickup_code, code_expire_at
• arrived_at, verified_at, verify_operator
• locker_cell（柜机格口，可空）

楼栋字典 campus_building

• campus_id, building_code, station_id, gate_rule（门禁时段 JSON）
• 新生季支持批量导入，禁止寝室号纯自由文本作为唯一履约坐标。

审计 order_audit_log

• order_id, from_status, to_status, reason_code, operator, at

索引至少覆盖：(campus_id, status, created_at)（档口拉单）、(user_id, created_at)（我的订单）、(station_id, status)（站点看板）、(status, code_expire_at)（超时未取扫描）、(sku_id, biz_date, period_tag)（库存）。

REST 与事件契约（草图）

学生端 / 商家端 / 骑手端打到同一后端，用角色鉴权拆开：

POST /api/v1/orders                    # 创建订单（预扣库存），Header: Idempotency-Key
POST /api/v1/orders/{id}/pay-callback  # 支付回调（验签后投递队列）
POST /api/v1/orders/{id}/accept        # 商家接单
POST /api/v1/orders/{id}/ready         # 出餐
POST /api/v1/fulfillments/{id}/pickup  # 骑手取餐
POST /api/v1/fulfillments/{id}/arrive  # 到站/入柜，幂等
POST /api/v1/fulfillments/{id}/verify  # 取餐码核销，幂等
POST /api/v1/stalls/{id}/pause         # 档口暂停接单（含恢复 ETA）
GET  /api/v1/stalls/{id}/orders:pull   # 商家批量拉单（替代每单一推）

领域事件（TDMQ/CMQ Topic 示例名）：

• order.paid
• order.accepted
• fulfillment.arrived
• fulfillment.verified
• fulfillment.timeout_unpicked
• stock.soldout
• stall.paused

支付回调只做验签、落库「已支付意图」、投递 order.paid；真正的接单通知、积分、订阅消息由消费者处理。回调堆积时队列削峰，保证最终一致，而不是把网关线程拖死。

午高峰削峰：网关限流、消息队列与库存预扣

午高峰时序：限流、排队、批量拉单、预计算库存

假设场景：11:45–12:15，单校区多档口，学生集中点热门套餐，骑手按楼栋聚合送驿站。推荐主路径时序：

1. 接入层：API 网关对 POST /api/v1/orders 做校区级令牌桶 + 用户级配额；超限返回业务码 RATE_LIMITED 与排队页可理解文案，而不是裸 5xx。静态菜单与楼栋配置走 CDN/Redis，小程序包体积持续控制，避免首屏把下单接口一起打爆。
2. 创建订单：校验营业态、履约方式、楼栋合法性 → 库存预扣 → 写 CREATED → 返回支付参数。幂等键：user_id + stall_id + cart_hash + 时间窗（按产品定义）。重复提交返回同一 order_id。
3. 支付回调：验签 → 标记支付意图 → 发 order.paid → 快速 200。消费者把预扣转实扣、推商家、写审计。
4. 商家侧：高峰不用「一单一推爆炸」；商家端轮询或长轮询 orders:pull，支持批量接单。档口可 pause，写入预计恢复时间，减少无效催单。
5. 出餐与取餐：ready 后生成/绑定运单；骑手端按 station_id 聚合列表，而不是按城市最短路在校园里绕圈。
6. 到站与核销：arrive 写 ARRIVED_STATION，生成短时有效取餐码（核销即失效，防截图盗用）；学生核销走 verify。超时扫描任务发 fulfillment.timeout_unpicked 并通知。

热门套餐可在开餐前预热 Redis 库存视图与「售罄」短缓存；售罄后短时间直接拒绝创建，保护 MySQL。压测门禁至少覆盖：整点前后十五分钟、单楼栋集中下单、支付回调堆积、骑手并发到站、取餐码重复核销。限流文案可读性也要测——技术活着但学生以为崩了，效果等同于崩了。

云上拼装示例（按需取舍，不是清单式硬广）：接入用 API 网关限流；交易服务跑云托管；尖峰消费者与超时扫描用云函数订阅 TDMQ；菜单与售罄标记进 Redis；订单与库存进云数据库 MySQL；商品图与售后图进 COS；网关 4xx/5xx、下单成功率、队列堆积、核销失败率进 CLS 告警。CloudBase 适合快速搭管理端或原型；一旦下单 QPS 与状态机复杂度上来，核心路径放到可水平扩的云托管更可控。

库存预扣与幂等：超卖和双花都出在这里

预扣伪流程（同一事务或「本地消息表 + 最终一致」）：

1. 按 sku_id + biz_date + period_tag 锁定库存行（乐观锁 version 或行锁）。
2. 若 available < qty，返回 STOCK_NOT_ENOUGH。
3. available -= qty，reserved += qty，写预扣流水（含 order_id）。
4. 写订单 CREATED。
5. 支付成功消费者：reserved -= qty，sold += qty。
6. 关单/支付超时：reserved -= qty，available += qty。

幂等要点：

• 下单：Idempotency-Key 落地唯一索引；冲突时查原单返回。
• 支付回调：按支付平台 transaction_id 去重；已处理直接 ACK。
• 到站 / 核销：order_id + action + idempotency_key；已是目标状态则返回成功回执，而不是「状态不允许」的假冲突。
• 退款：回滚正确餐段库存池；部分退要按行项目回滚，避免整单释放导致可售虚高。

失败模式要提前写进手册：预扣成功但写订单失败 → 事务回滚；支付成功但转实扣消费者失败 → 靠队列重试与对账任务，不能依赖人工改库；Redis 售罄标记与 MySQL 不一致 → 以 MySQL 为准、缓存设短 TTL 并提供强制刷新。

楼栋履约：地址模型、取餐码、运单事件

地址建议四级：campus → building → unit/floor（可选）→ station。履约模式在订单上锁定：

• 驿站/柜机：骑手送到站，学生凭码自取；管理成本相对可控，是默认推荐。
• 寝室直送：白名单楼栋 + 时段；门禁规则进 gate_rule。
• 到店自取：雨天运力不足或短距离食堂时，运营可一键把某楼栋切到自取优先并推送说明——配置变更，而不是群消息口头通知。

取餐码：短 TTL、核销即失效、站点管理员可异常核销并写原因码。柜机对接走标准化运单事件（fulfillment.arrived 带 locker_cell），避免每个硬件厂商一套硬编码。错拿餐治理 = 核销记录 + 抽检 + 站点责任人；技术侧保证「未核销不能标完成」。

骑手调度校园特化：按楼栋聚合优先于绝对最短路径；禁行区、停车点、考试周临时收紧都配置化。评价与完单率可作派单权重，但保留新手保护量，避免冷启动接不到单。

楼栋履约、失败模式与观测

失败模式、观测与学期容量

观测（CLS 等）建议分级：

• P1：下单成功率骤降、支付回调失败率、库存超卖检测、队列死信
• P2：接单延迟、到站延迟、核销失败率、单档口暂停占比
• P3：未取餐率、超时扫描积压、慢 SQL

容量与校历对齐：开学/考试周扩云托管副本与数据库规格，寒暑假缩；未完成退款、库存归档、账号冻结写进停服手册。多校区把差异收敛到配置（地址树、门禁、运力、支付商户号），禁止按校区拉代码分支。

安全侧：退款/改价/上下架审计；管理端角色拆分食堂、站长、校方只读；演练伪造 building_id 下单、刷券、恶意催单。统一身份对接可减少黑产小号；访客（校外骑手、临时商家）与学生分域。校园网下支付回调域名与证书提前报备；档口打印小票按弱网重试。

上线前最低测试矩阵

1. 同一 Idempotency-Key 重复下单（不双扣库存）
2. 并发抢最后一份时段库存（不超卖）
3. 支付回调重复投递（状态与库存仍一致）
4. 回调堆积时下单与接单仍可用（队列消费者可水平扩）
5. 骑手重复「到站」、学生重复核销（幂等）
6. 取餐码过期与超时未取流转
7. 档口暂停后新单拒绝、恢复后可下
8. 雨天切换楼栋履约模式的配置生效路径
9. 跨自然日餐段库存切日（UTC+8）
10. 伪造楼栋参数、越权接单、越权核销

常见工程坑：寝室号自由文本导致找不到人；不做排队页导致误判宕机；柜格失败仍显示送达；UTC 切日导致午餐库存错乱；ARRIVED_STATION 缺失导致未取餐无法统计；把订阅消息写进支付回调同步链。把这些写进运维手册，成本远低于开学第一周社群救火。

小结

校园外卖在工程上要优先保证四件事：订单/运单状态机可审计、库存预扣不超卖、接入层可限流可排队、支付与通知用消息队列削峰。楼栋字典、取餐码幂等核销、按站聚合调度，是履约稳定性的底座；API 网关、云托管、云函数、TDMQ/CMQ、Redis、云数据库 MySQL、COS、CLS 等是按边界拼装的零件，用「例如」对齐能力即可，不必绑死单一产品口号。UI 与运营位是触达手段；整点算不清、送不到站、追不到审计的系统，菜单再漂亮也只是把故障放大。先把第一食堂、第一批楼栋的状态机与削峰跑稳，再复制到下一校区，才是可持续的扩展方式。