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

最新推荐文章于 2024-07-26 11:06:08 发布

micklongen

最新推荐文章于 2024-07-26 11:06:08 发布

阅读量440

点赞数

分类专栏：系统架构文章标签：系统架构秒杀

本文链接：https://blog.csdn.net/micklongen/article/details/89763173

版权

系统架构专栏收录该内容

20 篇文章 0 订阅

订阅专栏

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 分钟）
库存超卖
- 对普通的商品下单数量超过库存数量的情况，可以通过补货来解决；
- 但是有些卖家完全不允许库存为负数的情况，那只能在买家付款时提示库存不足
库存优化
- 在缓存减库存
- 数据库并发锁问题
  - 热点数据隔离
  - 应用层做排队
  - 数据库层做排队