E. 业务场景 --- 秒杀系统

E. 业务场景 — 秒杀系统

概要

• 核心问题
  • 并发读
  • 并发写
• 秒杀的整体架构可以概括为“稳、准、快”几个关键字
  • 所谓“稳”，就是整个系统架构要满足高可用
  • 就是“准”，就是秒杀 10 台 iPhone，那就只能成交10 台，多一台少一台都不行。
  • 最后再看“快”，“快”其实很好理解，它就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？

架构设计原则

• 数据要尽量少
  • 首先是指用户请求的数据能少就少
  • 其次，“数据要尽量少”还要求系统依赖的数据能少就少
• 请求数要尽量少
• 路径要尽量短
• 依赖要尽量少
  • 系统降级减少依赖，我们可以给系统进行分级，比如 0 级系统、1 级系统、2 级系统、3 级系统
• 不要有单点

样例概述

• 第一阶段
  • 把秒杀系统独立出来单独打造一个系统，这样可以有针对性地做优化
  • 在系统部署上也独立做一个机器集群，这样秒杀的大流量就不会影响到正常的商品购买集群的机器负载
  • 将热点数据（如库存数据）单独放到一个缓存系统中，以提高“读性能”
  • 增加秒杀答题，防止有秒杀器抢单
• 第二阶段
  • 对页面进行彻底的动静分离，使得用户秒杀时不需要刷新整个页面
  • 在服务端对秒杀商品进行本地缓存，不需要再调用依赖系统的后台服务获取数据，甚至不需要去公共的缓存集群中查询数据，这样不仅可以减少系统调用，而且能够避免压垮公共缓存集群
  • 增加系统限流保护，防止最坏情况发生

高性能/高可用

• 关注点
  • 一点是提高单次请求的效率
  • 一点是减少没必要的请求
• 要点
  • 动静分离也就是所谓“动态”还是“静态”，并不是说数据本身是否动静，而是数据中是否含有和访问者相关的个性化数据。
    • 静态数据的处理
      • 你应该把静态数据缓存到离用户最近的地方
        • 浏览器
        • CDN
        • 服务器的Cache
      • 静态化改造就是要直接缓存 HTTP 连接Web 代理服务器根据请求 URL，直接取出对应的 HTTP响应头和响应体然后直接返回，这个响应过程简单得连 HTTP 协议都不用重新组装，甚至连 HTTP 请求头也不需要解析。
      • 让谁来缓存静态数据也很重要
    • 动态内容改造
      • URL 唯一化
      • 分离浏览者相关的因素浏览者相关的因素包括是否已登录，以及登录身份等，这些相关因素我们可以单独拆分出来，通过动态请求来获取。
      • 分离时间因素。服务端输出的时间也通过动态请求获取。
      • 异步化地域因素。详情页面上与地域相关的因素做成异步方式获取，当然你也可以通过动态请求方式获取，只是这里通过异步获取更合适。
      • 去掉 Cookie
    • 动态数据的处理
      • ESI 方案（或者 SSI）：即在 Web 代理服务器上做动态内容请求，并将请求插入到静态页面中，当用户拿到页面时已经是一个完整的页面了。这种方式对服务端性能有些影响，但是用户体验较好。
      • CSI 方案。即单独发起一个异步 JavaScript 请求，以向服务端获取动态内容。这种方式服务端性能更佳，但是用户端页面可能会延时，体验稍差。
    • 架构方案
      • 单机部署这种方案是将虚拟机改为实体机，以增大 Cache 的容量，并且采用了一致性 Hash 分组的方式来提升命中率。
        • 优点
          • 没有网络瓶颈，而且能使用大内存；
          • 既能提升命中率，又能减少 Gzip 压缩；
          • 减少 Cache 失效压力，因为采用定时失效方式，例如只缓存 3 秒钟，过期即自动失效；
        • 缺点
          • 一定程度上也造成了 CPU 的浪费，因为单个的 Java 进程很难用完整个实体机的 CPU。
          • 一个实体机上部署了 Java 应用又作为 Cache 来使用，这造成了运维上的高复杂度
      • 统一Cache：分布式缓存
        • 优点
          • 单独一个 Cache 层，可以减少多个应用接入时使用Cache 的成本。这样接入的应用只要维护自己的 Java 系统就好，不需要单独维护 Cache，而只关心如何使用即可。
          • 统一 Cache 的方案更易于维护，如后面加强监控、配置的自动化，只需要一套解决方案就行，统一起来维护升级也比较方便。
          • 可以共享内存，最大化利用内存，不同系统之间的内存可以动态切换，从而能够有效应对各种攻击。
        • 缺点
          • Cache 层内部交换网络成为瓶颈；
          • 缓存服务器的网卡也会是瓶颈；
          • 机器少风险较大，挂掉一台就会影响很大一部分缓存数据。
      • CDN
        • 问题
          • 失效问题
          • 命中率问题
          • 发布更新问题
        • 解决方案
          • 靠近访问量比较集中的地区；
          • 离主站相对较远；
          • 节点到主站间的网络比较好，而且稳定；
          • 节点容量比较大，不会占用其他 CDN 太多的资源；
  • 热点数据
    • 什么是热点
      • 热点操作
        • 读请求
        • 写请求
      • 热点数据
        • 静态数据热点：能够提前预测的数据例如，我们可以通过卖家报名的方式提前筛选出来，通过报名系统对这些热点商品进行打标。比如我们分析历史成交记录、用户的购物车记录，来发现哪些商品可能更热门、更好卖
        • 动态数据热点：系统运行过程总产生的热点例如，卖家在抖音上做了广告，然后商品一下就火了，导致它在短时间内被大量购买。
    • 问题
      • 首先，热点请求会大量占用服务器处理资源，虽然这个热点可能只占请求总量的亿分之一，然而却可能抢占 90% 的服务器资源，如果这个热点请求还是没有价值的无效请求，那么对系统资源来说完全是浪费
      • 其次，即使这些热点是有效的请求，我们也要识别出来做针对性的优化，从而用更低的代价来支撑这些热点请求。
    • 发现热点
      • 发现静态热点数据
        • 静态热点数据可以通过商业手段，例如强制让卖家通过报名参加的方式提前把热点商品筛选出来
        • 还可以通过技术手段提前预测，例如对买家每天访问的商品进行大数据计算，然后统计出 TOP N 的商品，我们可以认为这些 TOP N 的商品就是热点商品。
      • 发现动态热点数据
        • 步骤
          • 构建一个异步的系统，它可以收集交易链路上各个环节中的中间件产品的热点 Key
          • 建立一个热点上报和可以按照需求订阅的热点服务的下发规范，主要目的是通过交易链路上各个系统（包括详情、购物车、交易、优惠、库存、物流等）访问的时间差，把上游已经发现的热点透传给下游系统，提前做好保护。
          • 将上游系统收集的热点数据发送到热点服务台，然后下游系统（如交易系统）就会知道哪些商品会被频繁调用，然后做好热点保护
        • 注意事项
          • 这个热点服务后台抓取热点数据日志最好采用异步方式，因为“异步”一方面便于保证通用性，另一方面又不影响业务系统和中间件产品的主流程
          • 热点服务发现和中间件自身的热点保护模块并存，每个中间件和应用还需要保护自己。
          • 热点发现要做到接近实时（3s 内完成热点数据的发现）
      • 处理热点数据
        • 优化：对于热点数据，直接缓存
        • 限制：可以把热点商品限制在一个请求队列里，防止因某些热点商品占用太多的服务器资源，而使其他请求始终得不到服务器的处理资源
        • 隔离
          • 业务隔离
          • 系统隔离
          • 数据隔离
  • 削峰
    • 我们知道服务器的处理资源是恒定的，你用或者不用它的处理能力都是一样的，所以出现峰值的话，很容易导致忙到处理不过来，闲的时候却又没有什么要处理。但是由于要保证服务质量，我们的很多处理资源只能按照忙的时候来预估，而这会导致资源的一个浪费
    • 好处
      • 一是可以让服务端处理变得更加平稳
      • 二是可以节省服务器的资源成本
    • 解决思路
      • 排队
        • 消息队列
        • 线程池
        • 先进先出、先进后出等常用的内存排队算法的实现方式
      • 答题
        • 第一个目的是防止部分买家使用秒杀器在参加秒杀时作弊
        • 第二个目的其实就是延缓请求，起到对请求流量进行削峰的作用，从而让系统能够更好地支持瞬时的流量高峰。
      • 过滤：在不同的层次尽可能地过滤掉无效请求，让“漏斗”最末端的才是有效请求
        • 大部分数据和流量在用户浏览器或者 CDN 上获取，这一层可以拦截大部分数据的读取；
        • 经过第二层（即前台系统）时数据（包括强一致性的数据）尽量得走 Cache，过滤一些无效的请求；
        • 再到第三层后台系统，主要做数据的二次检验，对系统做好保护和限流，这样数据量和请求就进一步减少；
        • 最后在数据层完成数据的强一致性校验

一致性

• 减库存的方式
  • 下单减库存：但是你要知道，有些人下完单可能并不会付款
  • 付款减库存：有可能出现买家下单后付不了款的情况，因为可能商品已经被其他人买走了
  • 预扣库存：买家下单后，库存为其保留一定的时间（如 10 分钟）
• 库存超卖
  • 对普通的商品下单数量超过库存数量的情况，可以通过补货来解决；
  • 但是有些卖家完全不允许库存为负数的情况，那只能在买家付款时提示库存不足
• 库存优化
  • 在缓存减库存
  • 数据库并发锁问题
    • 热点数据隔离
    • 应用层做排队
    • 数据库层做排队

限流降级