Expert guidance for building s…

# 外卖接单系统：分库分表 + 幂等设计

一、订单表分库分表方案

容量评估

• 5000并发峰值、外卖订单日单量预估百万级，单表超千万行会出现明显性能劣化，建议预留3~5年增长空间。

分片策略

• 分片键选择：优先用 user_id 取模，便于用户侧查询（我的订单）；如商户侧查询频繁，可用基因法——在订单号中嵌入 user_id 后几位，兼顾商户表冗余分片。
• 分片数量：建议 4~8 个库 × 每库 16~32 张表（如 4库×32表=128张），一次到位避免后续扩容翻倍迁移。
• 订单号设计：雪花算法生成全局唯一订单号，可将分片位编入订单号，实现免路由表查询。

中间件选型

• ShardingSphere-JDBC（无代理层、性能好）或 MyCat；团队熟悉度优先。

索引与查询设计

• 每张分表保留：订单号、user_id、merchant_id、状态、时间等字段索引。
• 非分片键查询（如骑手维度、运营后台）走 异构索引：通过 Binlog + Canal 同步到 ES 或单独的聚合库。

历史数据

• 已完成订单按月归档到历史库/冷存储，保持热表轻量。

二、防重复下单的接口幂等实现

核心思路：客户端生成唯一请求标识 + 服务端去重校验。

1. 前端防抖

• 提交按钮置灰 + 防重复点击，生成 idempotency_key（如 UUID）随请求提交。

2. 服务端三重防护

• 分布式锁（第一道）：以 idempotency_key 或 user_id + meal时间窗 为 key 加 Redis 锁（SET NX EX，锁时长覆盖请求处理周期），拦截并发重复请求。

• 唯一索引兜底（最终保障）：订单表对 idempotency_key 或 user_id + 业务批次号 建唯一索引，插入冲突即视为重复，捕获异常返回原订单结果。

• 状态机校验：订单流转严格校验前置状态（如“待支付→已支付”），非法流转直接拒绝。

3. Redis 去重表方案

• 处理成功后将 key 写入 Redis（TTL 如 24 小时），后续相同 key 直接返回首次结果（可缓存原响应体，实现“幂等返回”）。

4. 注意事项

• Redis 与 DB 非强一致，Redis 判断仅作快速拦截，DB 唯一索引是最终防线，两者必须都有。
• 下单接口与扣库存、创建订单应在同一事务或通过消息最终一致。
• 幂等 key 需约定 TTL 与重试语义（重复请求返回相同结果，而非报错）。

落地优先级：唯一索引（必做）> Redis 锁（必做）> 前端防抖（体验优化）> 响应缓存（增强）。