01 它是干嘛的
这里讲的不是「怎么开店」，而是淘宝天猫背后的电商中台：交易、库存、订单、履约、推荐、风控等多个系统协同，把「逛、加购、下单、支付、发货、收货」整条链路支撑起来，并在大促秒杀时保证系统稳定与库存准确。
02 为什么会有它
为什么「抢购」这件事，对系统是一场硬仗
电商表面看是「买家下单、卖家发货」，背后却是一整套复杂系统在协同。用户浏览商品时，背后是推荐系统在决定给他看什么；点下「立即购买」时，系统要同时检查库存、生成订单、扣减优惠、锁定商品；付款后，还要触发履约、通知仓库、安排物流、更新状态。任何一个环节出问题，用户看到的都是「下单失败」。
最难的是秒杀。一件商品只放 100 件，却可能有几十万人同时点「抢购」。系统一瞬间要承受平时几十倍的流量，还要保证既不能超卖（卖出 101 件），也不能把前面的人堵死。这时候「库存扣减」和「限流」就成了两道关键闸门——既要扣得准，又要让流量有序通过。
为此电商演化出了一整套「中台」做法：把交易、库存、订单、履约、推荐、风控等能力沉淀成可复用的公共系统，不同业务线共用同一套底座。这套架构正是被淘宝天猫的双十一级别流量反复锤炼出来的，也是理解现代大型电商系统的通用样本。
03 它怎么工作
秒杀的核心是把「瞬时洪峰」拆解成有序步骤：先用限流与排队拦住过量请求，再用缓存与预扣减保证库存不超卖，最后异步落单、慢慢处理后续，让前端始终快速响应。
一次秒杀下单，系统背后经历了什么
- 1① 活动前预热
把商品信息、库存预热到缓存中，页面与数据提前准备好，避免活动开始瞬间才去查数据库。
- 2② 流量限流与排队
入口处按规则限制请求速率，超出的请求被排队或直接拒绝，防止洪峰把后端彻底压垮。
- 3③ 库存扣减
在缓存里做原子扣减，只有扣减成功的请求才继续往下走，这是防超卖最关键的一道关卡。
- 4④ 生成订单
扣减成功的请求生成订单并进入处理队列，下单动作与后续的履约、通知解耦，前端能快速得到结果。
- 5⑤ 异步履约与对账
订单被异步处理：通知仓库、安排物流、更新状态；同时有对账机制检查库存与实际订单是否一致。
04 谁在用它
学习交易、库存、订单、履约、推荐、风控如何分工协作，是系统设计的经典案例。
限流、缓存预热、库存预扣减、异步处理等做法，被广泛借鉴到其他高并发场景。
从海量商品中筛选用户可能喜欢的，再排序展示，是推荐系统「召回加排序」的典型应用。
下单瞬间识别异常账号与可疑行为，保护买卖双方与平台安全。
商家通过开放接口对接商品、订单、物流等数据，把自有系统与平台打通。
05 怎么用
这里把它当成「系统设计案例」来理解；若要接入平台能力，则通过开放平台提供的接口开发。
- 01先理解电商链路：浏览、加购、下单、支付、发货、收货、售后，每一步都有对应系统。
- 02识别各个环节的关键难点：库存扣减要准、流量要限、状态要一致。
- 03学习通用的应对手段：缓存、限流、队列、异步、幂等、对账。
- 04如需对接平台，到开放平台注册应用，获取凭证后调用商品、订单等接口。
- 05用沙箱环境做联调，确认订单状态流转与对账逻辑正确后再上线。
# 关键：库存扣减要用原子操作，且只让成功的那一个请求继续
result = cache.decr_if_enough(key="stock:sku_1001", count=1)
if result == -1:
return "已售罄" # 库存不足，直接返回
else:
# 扣减成功，进入订单队列异步处理，前端立即返回「下单中」
order_queue.push(user_id=42, sku="sku_1001")
return "下单成功，正在处理"避坑提示
- !防超卖的关键是「原子扣减」，多个请求同时来时必须由一次不可分割的操作决定谁成功，不能先查再改。
- !库存与订单之间要靠对账兜底，缓存里的库存与数据库最终要能对上，出现偏差要能及时发现。
- !幂等很重要：用户重复点击、通知重复到达时，同一笔下单不能重复生成订单。
06 关键概念
- 电商中台
- 把交易、库存、订单等能力沉淀成公共系统，供多个业务线复用，避免各做一套。
- 超卖
- 库存只有 100 件却卖出了 101 件，通常源于并发扣减没有做到原子操作。
- 限流
- 限制单位时间的请求量，超过部分排队或拒绝，保护后端不被瞬时洪峰压垮。
- 召回与排序
- 推荐系统的两步：先从海量商品里粗筛出一批候选，再精细排序决定展示顺序。