一、秒杀到底难在哪？

假设你开了一家线上商店。今天做活动：1块钱抢最新款手机，只有100台。消息公布后，瞬间来了10000个人。

这时候会遇到三个致命问题：

我们的设计目标就三条：抗住高并发、保证不超卖、防刷防重复。怎么说呢，

二、主要设计思想：漏斗模型

不要把所有请求都直接冲到数据库。而是像漏斗一样，一层一层过滤掉无效流量,最终真正落到数据库的只有少量有效请求。

使用者请求 ↓ 按钮防抖、验证码 → 拦截手抖党和脚本 ↓ Nginx限流 → 每IP每秒只放行10个请求 ↓ Redis原子扣库存 + 分布式锁防重复 → 主要战场 ↓ 异步下单 → 削峰填谷。保护数据库 ↓ 最终落库 → 压力已削减99%

每一层都在"拦截",让无效请求尽早返回"已售罄"或"太火爆",绝不往下一层传递。话说回来，

三、分层详解 + 代码实战

. 前端层：把"手速党"和"脚本党"拦住

• 说到做法。点击秒杀按钮后立即变灰,5秒内不能重复点；加上简单验证码，
• 这步虽简单,但能有效减少80%的无效重复请求。后端必须做校验,前端只是辅助。
• 说到示例代码，

  
  // 按钮防重复点击
  document.getElementById.onclick = function {
  this.disabled = true;
  this.innerText = '正在抢购...';// 实际发起请求
  doSeckillRequest;怎么说呢，// 5秒后恢复
  setTimeout => {
  this.disabled = false;this.innerText = '立即秒杀';},)，};

. 网关层：限流,只放行一部分

• 做法的观点是。用Nginx的`limit_req`模块,限制每个IP每秒最多10个请求,突发20个,超过的直接返回503。
• 再看示例配置，

  
  # nginx.conf
  http {
  #定义限流区域,按IP。内存大小可根据实际情况调整
  limit_req_zone $binary_remote_addr zone=seckill_limit:1m rate=;server {
  location /seckill {
  #允许突发数量为nodelay表示不缓冲延迟直接拒绝)
  limit_req zone=seckill_limit burst=nodelay;limit_req_status;proxy_pass http://backend_servers;不过，}
  }
  }
  

从.业务层来看。Redis原子扣库存

• 主要原因这方面，将商品信息提前预热到Redis中；按理说，使用Lua脚本保证查询判断扣减是原子操作。

  lua-- KEYS : 库存Key,例如 seckill_stock:productId=ARGV :要扣减的数量endif tonumber