秒杀系统设计总结

简介

秒杀从规模上可以分为以下两类：

• 大秒：类似双十一，商品数量规模大，价格低，流量超大的活动。
• 小秒：商家自己配置的一些时段类型的活动，由商家自己指定时间上架。

秒杀系统面对的问题

秒杀系统本质上就是一个满足大并发、高性能和高可用的分布式系统。

• 高并发环境下的系统稳定性：如何保证系统在面对巨大的流量情况下，不被打崩？
  • 两个问题
    • 并发读
      • 核心优化理念：减少用户到服务端来读数据。或者让他们读取更少的数据。
    • 并发写
      • 核心优化理念：在数据库层面独立出来一个库，做特殊的处理。
  • 大流量会产生以下实际待解决问题
    • Redis缓存击穿/雪崩/穿透等问题
    • 关系型数据库性能问题，锁竞争对性能的消耗
• 保证数据的最终一致性：库存不能超卖。
• 大数据分析功能：分析本次秒杀活动的商业效益。
• 需要有一个兜底方案，以防最坏的情况发生。

设计

架构原则： “4要1不要”

架构是一种平衡的艺术，最好的架构一旦脱离了它所适应的场景，一切都将是空谈。

• 数据要尽量少

  • 用户请求的数据能少就少，包括上传给系统的数据和系统返回给用户的数据。

• HTTP请求数尽量少

  • 合并CSS，JS文件

• 路径要尽量短

  • 用户发出请求到返回数据的过程中，经过的节点要尽量短
    • 通常，每经过一个节点，都会产生一个新的Socket连接。
  • 会减少时延
  • 可以选择将多个相互强依赖的引用部署在一起，将RPC变成JVM内部的方法调用

• 依赖要尽量少

  • 完成一次用户请求必须依赖的系统或服务要少（指的是强依赖）
    • 比如展示秒杀页面，它强依赖商品信息，用户信息，但是优惠券，成交列表等非必要模块是可以在紧急情况下去掉。
  • 对系统模块进行分级，0级，1级，2级等

• 不要有单点

  • 系统中的单点是系统架构上的一个大忌，单点意味着没有备份，风险不可控。
    • 如何避免单点？
      • 避免将服务的状态和机器绑定（服务无状态化）
        • 把服务的配置动态化（使用配置中心Nacos等）
        • 存储服务不好实现，因为数据持久化存储在机器的磁盘里面。文件存储可以通过冗余多个备份的方式来解决单点问题。

流量过滤

本质：逐级过滤掉无效的流量。基本有以下一些解决方案：

• 活动开始前前端页面的Button无法点击，防止活动尚未开始时，用户进行点击产生流量。
  • 同时后端需要做相关校验。避免用户直接请求秒杀接口。
  • 秒杀url实现动态化，可以选择进行md5加密随机字符串，然后通过另一个接口校验秒杀接口的合法性
• 错峰：前端添加验证码或者答题，防止瞬间产生超高的流量，增加题目辨别难度，避免以图像识别等技术进行破解。
• 校验：对参与活动的用户进行校验拦截。主要从以下几个方面进行判断
  • 用户白名单
  • 用户终端校验：对用户终端类型进行判断
  • IP、MAC、ID校验
  • 参与次数校验：避免多次参与活动
  • 用户黑名单：避免羊毛党等
• 限流：通过接口限流策略判断请求是否放行
  • 令牌桶算法

性能优化

前面的流量过滤基本过滤掉大部分流量，但是系统性能还需进行优化，主要有以下的解决方案：

• 动静分离
• 活动预热：将参加活动的商品独立出来，不和普通的商品库存共享服务，提前将数据缓存到Redis，查询全部走缓存，扣减库存视情况而定。
• 选择Nginx
• 采用微服务架构部署，提高部署量，均摊请求。
• 秒杀是典型的读多写少的场景，考虑到单体redis的性能问题，可以考虑：
  • Redis集群
  • 主从同步
  • 读写分离
  • 如果使用Redis集群，同时需要考虑保证多节点的数据一致性
• 异步处理：采用消息队列
  • 异步，削峰，解耦

动静分离

“动态数据”和“静态数据”的主要区别就是看页面中输出的数据是否和 URL、浏览者、时间、地域相关，以及是否含有 Cookie 等私密数据。

简而言之，静态数据是能不经过后端请求，直接输出给用户的数据，

如何对静态数据做缓存？

• 把静态数据缓存到离用户最近的地方。
  • 用户浏览器
  • CDN
    • 失效问题
    • 命中率问题
    • 发布更新问题
  • 服务器端Cache
• 静态化改造就是直接缓存HTTP连接。
  • 静态化改造是直接缓存 HTTP 连接而不是仅仅缓存数据。Web代理服务器直接根据请求URL，取出对应的HTTP响应头和响应体然后直接返回。
• 选择缓存性能优秀的工具进行缓存服务，可以在Web服务器层面进行缓存，例如Nginx，Apache。

如何做动静分离的改造？

• URL唯一化，每个商品由ID来标识。item.xxx.com/item.htm?id=xxxx 就可以作为唯一的 URL 标识。
  • URL唯一可以根据id作为key，查询之前缓存的HTTP连接。
• 分离浏览者相关的因素。登录状态可以通过请求获取
  • JWT
• 分离时间因素。服务端输出的时间也通过请求获取。
• 异步化地域因素：详情页面上的地域信息做成异步方式获取。
• 去掉Cookie，可以通过Web服务器删除服务器输出的页面中的Cookie。

动态数据的处理方式

• ESI方案：在Web代理服务器上做动态内容请求，并将请求插入到静态页面中。当用户拿到页面时已经是一个完整的页面了。这种方式对服务端性能有些影响，但是用户体验较好。
• CSI方案：即单独发起一个异步 JavaScript 请求，以向服务端获取动态内容。这种方式服务端性能更佳，但是用户端页面可能会延时，体验稍差。

解决超卖

一般情况下，减库存有以下方式：

• 下单减库存：是最简单的方式，也控制的最精准。但是存在恶意锁单等问题。
• 付款减库存：大并发的情况下，可能存在买家下单后无法付款的问题。
• 预扣库存：买家下单后，库存为其保留一定时间，超时未付款自动释放库存

如果扣库存逻辑较为简单，比如没有复杂的SKU库存和总库存这种联动关系的话，可以选择在Redis完成减库存。Redis定时更新到MySQL。

复杂秒杀场景选择的方式：

1. 首先查询Redis缓存库存是否充足
2. 先扣库存再落订单数据，以防订单生成没有了库存的超卖问题
3. 扣库存先扣数据库，再扣Redis，并且两个操作需要在同一个事务中，一个执行失败全部回滚。
   • 数据库MySQL更新可以采取乐观锁方式，添加version字段进行处理，性能较悲观锁高。

上述方案能一定程度解决问题，但是如果大量请求线程落在同一条库存记录上去update时，会造成InnoDB行锁的竞争问题，而并发度越高等待的线程会越多，TPS（Transaction Per Second）会下降，相应时间上升，数据库的吞吐量会严重受影响。

这时，需要做数据库层面的优化。

质量保障

• 熔断限流降级
• 监控：QPS监控，容器监控，CPU监控，IO监控等
• 提前压测

数据统计

• 埋点，检测
• 数据大盘，通过数据库数据配合监控系统（首选）
• 离线数据分析