初始模型：
用户下单 → 参数/权限校验 → 检查库存 → 创建订单 → 用户支付 → 支付回调更新状态；如果超时未支付 → 取消订单 → 恢复库存。
然后秒杀场景下逐步演进：
- 总量限流：瞬时 QPS 远超系统承载能力 → 先按系统容量做粗粒度限流，超过直接失败
- 请求过滤：无效请求、脚本、恶意流量很多 → 参数校验、活动校验、人机验证
- 细粒度限流：单个用户/IP 可能疯狂请求 → 按用户、IP、设备限制频率
- Redis 预热：不能让所有请求直接查数据库 → 活动前把商品和库存提前放到 Redis
- 原子预扣库存：高并发下必须防止超卖 → 用 Lua 等方式在 Redis 中原子判断并扣库存
- 快速失败：大部分用户最终抢不到 → 库存不足直接在 Redis 层返回，不进入后续链路
- MQ 削峰：预扣成功后的瞬时下单写流量仍然很大 → 写入消息队列，接口先返回“排队中”
- 异步下单：数据库不能承受瞬时写入 → 消费者按自身能力慢慢创建订单
- 消息可靠：不能出现库存扣了但订单消息丢了 → 持久化、ACK、失败重试
- 消费幂等：消息可能重复投递 → 用订单唯一约束等方式保证只创建一次
- 超时取消：用户抢到后不支付会一直占库存 → 设置支付超时并自动取消
- 库存补偿：订单失败或超时取消后库存要恢复 → 将预扣库存补回
- 热点保护：超大活动可能把单个 Redis Key 打热 → 读副本、本地缓存、Key 拆分等方式分摊压力
最后脑子里只要保留一条主线：
普通下单 → 挡流量 → Redis 抢库存 → MQ 削峰 → 异步下单 → 可靠性/幂等 → 超时补偿。