面试题之如何设计一个秒杀系统？

系统痛点：

痛点分析：

• 瞬时并发量大：大量并发请求瞬间涌入，网站流量激增，可能压垮系统。
• 库存少：访问请求远大于库存，只有少量用户可以秒杀成功
• 架构设计原则：
  • 系统隔离：
    • 独立部署秒杀服务，避免影响主线业务流程
    • 独立数据库/缓存集群等
    • 独立域名/CDN等
  • 分层削峰：
    • 前端层：静态化、请求拦截
    • 服务层：队列缓冲、异步处理
    • 数据层：预减库存、最终一致

业务流程：

用户 → CDN → 负载均衡 → 网关(限流) → 秒杀服务 → 消息队列 → 订单服务
                                   ↘ Redis集群 ↘ 数据库集群

实施与解决

系统设计图：

分层设计：

以上为秒杀系统的设计图：根据访问层、负债层、服务层、业务层支撑层、数据层阐述设计

访问层

当用户访问系统商品时，需要将商品从动态网页转为静态网页。减少动态请求到服务端的压力，服务端只需要处理秒杀即可

前端上做一些逻辑处理：

• 静态资源分离：将活动页静态化，部署到CDN上
• 活动前禁用按钮：减少不必要的资源请求
• 按钮防重复点击：当用户点击提交后，立即灰显禁用，限制用户多次提交页面
• 随机延迟请求：客户端随机添加微笑言辞
• 验证码/答题：通过滑动验证码、图形验证码等拦截机器人及防止用户控制多个设备进行提交
• 排队体验：增加等待中、抢购中的提示，防止 用户多次刷新

服务层

        前端校验通过后，通过多台NG的转发，到后端处理秒杀功能，单台ng可以处理2-3万的数据量，一旦NG集群了，就需要在NG上方进行部署网络及硬件级别相关的F5/LVS等。通过NG校验及转发后，就会到服务端的网关集成器，比如ribbon或者loadbalancer进行客户端的负债均衡的转发，通过上面四级的负债均衡大概能处理每秒10+万的qps请求并发量。

• 网关限流操作：
  • 限流熔断：NG/Lua实现IP/用户限流
  • 请求过滤：恶意请求识别与拦截
  • URL动态化：活动开始前不暴露真实的接口
  • DNS轮询：让DNS服务商针对网站提供的域名绑定多个IP地址
• 支撑层
  • 异步处理：请求先入队列，异步处理订单
  • 缓存预热：提前加载热点数据到redis
  • 分层校验：
    • 第一层：用户资格校验（是否登录、黑名单等）
    • 第二层：库存校验（redis预扣减库存）
    • 第三层：最终校验（数据库确认）
    • 接口防重校验：（防止绕过前端的恶意用户刷单，setNX保证同一个时间、同一个商品、同一用户只能下单成功一次）
  • 库存方案：
    • 库存分段：将库存拆分成多个段（如1000库存拆成10个100）
    • 预扣库存：redis预减库存（LUA脚本进行数据操作），异步（秒杀时客户端将请求放到MQ消息中发送给MQ服务端，消息者通过消费队列来进行下单操作并持久化到数据库）同步到DB
    • 库存回滚：支付超时后自动释放库存
• 数据一致性：
  • 最终一致性：通过消息队列异步处理
  • 事务消息：通过rocketMQ事务宝恒下单与扣减库存
  • 对账系统：定期核对redis与数据库的库存告警监控
  • 日志监控：防止系统出现问题后处理

限流相关：

• 核心要点：
  • NG需要配置限流，防止恶意绕过我们前端的一些D DOS攻击；
  • 网关sentinel对不同的服务节点限流和熔断机制；
  • 通过MQ的来削峰，通过MQ来减轻下游的服务压力
• 降级方案