系统设计——秒杀系统设计

庄小焱

已于 2024-11-07 19:16:01 修改

阅读量7.5k

点赞数 14

分类专栏：软件系统设计文章标签：大数据

于 2022-07-13 14:00:14 首次发布

未经同意窃取和转载我的内容，如果涉及到权益问题，后果自负！

本文链接：https://blog.csdn.net/weixin_41605937/article/details/125762408

版权

软件系统设计专栏收录该内容

56 篇文章 47 订阅

订阅专栏

摘要

秒杀大家都不陌生。自2011年首次出现以来，无论是双十一购物还是 12306 抢票，秒杀场景已随处可见。简单来说，秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统需要进行哪些关注。博文主要介绍有关于秒杀系统的设计和底层实现原理。

一、秒杀业务的流程

1.1 整体业务流程

通过对需求分析，我们提炼出秒杀活动的三大子流程，即：

(运营)创建秒杀活动；
(运营/买家)查看秒杀活动；
(买家)参与秒杀活动；

有了这个整体把握，我们再针对每一个子流程，分析该场景下需要编排哪些产品功能。

1.2 创建秒杀活动

创建秒杀活动：做的事情很简单，需要配置好活动场次，每个场次又需配置参与活动的秒杀商品；这个功能点，主要是面向运营，为了方便运营完成活动配置编辑，附带着还需提供活动查询能力：如查看活动列表、活动详情、发布/禁用活动等mis接口。

1.3 查看秒杀活动

查看秒杀活动：主要功能为支持秒杀会场的活动列表、秒杀商品列表、秒杀商品详情等活动页面；这些都是直接面向C端用户的系列读接口，承载流量会很高。

1.4 参与秒杀活动

查看秒杀活动：这一块核心述求是要能正确高效完成库存扣减，严格保证不能出现超卖！从功能点上来看，C端买家下单实现秒杀商品库存扣减，如果买家在规定时间未完成支付或拍下后取消订单，需及时释放用户下单锁定的库存，也就是要回库存。

二、秒杀系统概要设计

2.1 E-R 关系图

E-R关系图，用于指导如何建立领域模型。从E-R图上我们能看出，几个比较重要的领域模型：如活动、活动商品，系统真正编码落地的时候，紧紧围绕这些领域模型去建模，做到代码和领域模型的表达一致的。

2.2 产品边界

概要设计的目的是为了明确产品功能和系统边界，通过领域驱动的界限上下文图，能清晰地看出完成当前需求需要参与协作的团队，以及团队与团队之间任务划分边界。活动上下文是我们关注的重点，同时也应该看到，我们需要商品团队、交易团队的协作。

2.3 接口定义

通过概要设计划清了系统边界，每部分每个团队应该做什么就容易确定了，Api定义呼之欲出。

2.3.1 配置活动

定义

- 设置活动、活动商品、活动库存、开始结束时间等配置
- 系统需为每场活动分配全局唯一活动id: 若提交的数据带有活动id，则表示更新

接口变更: 新增接口
Api: POST http://${domain}/api/v1/activity/save
输入

{
  "activityName": "双十一秒杀第一场",
  "startTime": 1540174800000, // 活动开始时间
  "endTime": 1541988000000, // 活动结束时间
  "itemLine": [
    {
      "itemId": 123, // 活动商品id
      "itemType": 7, // 活动商品类型
      "itemTitle": "这是商品标题",
      "subTitle": "这是商品副标题",
      "itemImage": "这是图片链接",
      "salePrice": 66800, // 商品原价(单位:分)
      "activityPrice": 100, // 活动价
      "quota": 3, // 单个用户商品抢购件数限制
      "stock": 100 // 商品活动库存
    }
  ],
  "activityRuleConfigs": [ // 活动规则列表
    {
      "configKey": "city", // 城市规则：在规则列表的城市可看到活动
      "configValue": "17,5,10,2,3,4,11"
    }
  ]
}

输出

{
  "traceId": "2910c88d0d4f45d5fe299f0c5829d72c",
  "code": "SERVICE_RUN_SUCCESS",
  "msg": "服务运行成功",
  "status": 10000,
  "success": true
}

2.3.2 活动列表

定义

- 返回已创建的全部活动简要信息(不包含活动商品及销量)

接口变更: 新增接口
Api: POST http://${domain}/api/v1/activity/list
输入: 无
输出

{
  "traceId": "2910c88a0d4f45d5be290f0c5829d72c",
  "success": true,
  "status": 10000,
  "msg": "OK",
  "code": "SUCCESS",
  "data": [
    {
      "activityId": 1,
      "activityName": "双十一秒杀第一场",
      "startTime": 1541901600000,
      "endTime": 1741951999000,
      "enabled" true
    }
  ]
}

2.3.3 活动详情

定义

- 返回指定活动详细信息(包含活动商品及其销量)

接口变更: 新增接口
Api: GET http://${domain}/api/v1/activity/detail
输入: activityId=1
输出

{
  "traceId": "889924ef8e6241a7a766107f38c5e0c0",
  "success": true,
  "status": 10000,
  "msg": "OK",
  "code": "SUCCESS",
  "data": {
    "activityId": 1,
    "activityName": "双十一秒杀第一场",
    "startTime": 1541901600000,
    "endTime": 1741951999000,
    "enabled" true
    "items": [
      {
        "itemId": 53725,
        "itemType": 1,
        "itemTitle": "x商品",
        "subTitle": "x商品副标题",
        "itemImage": "http://img.xxxx.com/static/do1_QtSq1m2xM7VL6zEI4sUH",
        "itemPrice": 19800,
        "activityPrice": 4800,
        "quota": 3,
        "stock": 50,
        "sold": 0
      },
      {
        "itemId": 53724,
        "itemType": 1,
        "itemTitle": "y商品",
        "subTitle": "y商品副标题",
        "itemImage": "http://img.xxxx.com/static/MrcNjUeeoOG24zZH7nR.png",
        "itemPrice": 42800,
        "activityPrice": 17000,
        "quota": 3,
        "stock": 50,
        "sold": 0
      }
    ]
  }
}

2.3.4 活动商品详情

定义

- 返回活动商品详细信息(包含活动商品销量、活动信息)

接口变更: 新增接口
Api: GET http://${domain}/api/v1/activity/itemDetail
输入: activityId=1&itemId=53725
输出

{
  "traceId": "a77edf653da644959d331b7b55607958",
  "success": true,
  "status": 10000,
  "msg": "OK",
  "code": "SUCCESS",
  "data": {
    "itemId": 53724,
    "itemType": 1,
    "itemTitle": "x商品",
    "subTitle": "商品副标题",
    "itemImage": "http://img.xxxx.com/static/do1_QtSq1m2xM7VL6zEI4sUH",
    "itemPrice": 42800,
    "activityPrice": 17000,
    "quota": 3,
    "stock": 50,
    "sold": 0,
    "activity": {
      "activityId": 1,
      "activityName": "双十一秒杀第一场",
      "startTime": 1541901600000,
      "endTime": 1741951999000,
      "enabled" true
    }
  }
}

2.2.5 扣库存

定义

- 扣活动库存、扣用户参与抢购资格(注: 不局限Http接口，可采用Dubbo调用；此处仅方便演示)

接口变更: 新增接口
Api: POST http://${domain}/api/v1/stock/reduce
输入

{
  "activityId": 1,
  "buyerId": "buyer_001",
  "itemId": 53724,
  "orderId": "20191111123456789",
  "orderTime": 1541901700000,
  "quantity": 1
}

输出

{
  "traceId": "f689852f113e413d9940ce24020e7083",
  "success": true,
  "status": 10000,
  "msg": "OK",
  "code": "SUCCESS",
  "data": true
}

2.3.6 回库存

定义

- 回商品活动库存、回用户参与资格；可看做是扣库存的逆向操作；(注: 笔者在真正实现时，未采用Http接口，而是通过监听订单MQ来异步回库存)

接口变更: 新增接口
Api: POST http://${domain}/api/v1/stock/cancelReduce
输入

{
  "activityId": 1,
  "orderId": "20191111123456789"
}

输出

{
  "traceId": "5342243fd424468ab9ad13d03ffcdc62",
  "success": true,
  "status": 10000,
  "msg": "OK",
  "code": "SUCCESS"
}

三、秒杀系统详细设计

3.1 创建秒杀活动

3.2 查看秒杀活动

3.3 参与秒杀活动

四、秒杀系统的背景与特点

秒杀特点：短时间内，大量用户涌入，集中读和写有限的库存。

解决方案：层层拦截，将请求尽量拦截在系统上游，避免将锁冲落到数据库上。

4.1客户端优化

产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求； JS层面，限制用户在x秒之内只能提交一次请求，比如微信摇一摇抢红包。基本可以拦截80%的请求。

4.2 站点层面的请求拦截

怎么防止程序员写for循环调用，有去重依据么? IP? cookie-id? …想复杂了，这类业务都需要登录，用uid即可。在站点层面，对uid进行请求计数和去重，甚至不需要统一存储计数，直接站点层内存存储（这样计数会不准，但最简单，比如guava本地缓存）。一个uid，5秒只准透过1个请求，这样又能拦住99%的for循环请求。对于5s内的无效请求，统一返回错误提示或错误页面。

这个方式拦住了写for循环发HTTP请求的程序员，有些高端程序员（黑客）控制了10w个肉鸡，手里有10w个uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照uid限流拦不住了。

4.3 服务拦截层

方案一：写请求放到队列中，每次只透有限的写请求到数据层，如果成功了再放下一批，直到库存不够，队列里的写请求全部返回“已售完”。

方案二：或采用漏斗机制，只放一倍的流量进来，多余的返回“已售完”，把写压力转换成读压力。读请求，用cache，redis单机可以抗10W QPS,用异步线程定时更新缓存里的库存值。

还有提示“模糊化”，比如火车余票查询，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票。

4.4 数据库层

浏览器拦截了80%，站点层拦截了99.9%并做了页面缓存，服务层又做了写请求队列与数据缓存，每次透到数据库层的请求都是可控的。 db基本就没什么压力了，通过自身锁机制来控制，避免出现超卖。

4.5 总结：

尽量将请求拦截在系统上游（越上游越好）；
读多写少的多使用缓存（缓存抗读压力）；

五、秒杀系统可能存在的问题

对于一个日常平稳的业务系统，如果直接开通秒杀功能的话，往往会出现很多问题

用户	问题分类	业务出现的问题	设计要求
用户	体验较差	秒杀开始，系统瞬间承受平时数十倍甚至上百倍的流量，直接宕掉	高性能
用户		用户下单后却付不了款，显示商品已经被其他人买走了	一致性
商家	商品超卖	100 件商品，却出现 200 人下单成功，成功下单买到商品的人数远远超过活动商品数量的上限	一致性
	资金受损	竞争对手通过恶意下单的方式将活动商品全部下单，导致库存清零，商家无法正常售卖	高可用
		秒杀器猖獗，黄牛通过秒杀器扫货，商家无法达到营销目的	高可用
平台	风险不可控	系统的其它与秒杀活动不相关的模块变得异常缓慢，业务影响面扩散	高可用
	拖垮网站	在线人数创新高，核心链路涉及的上下游服务从前到后都在告警	高性能
		库存只有一份，所有请求集中读写同一个数据，DB 出现单点	高性能

秒杀本质是要求一个瞬时高发下的承压系统，这也是其区别于其他业务的核心场景。对日常系统秒杀产生的问题逐一进行拆解分类，秒杀对应到架构设计，其实就是高可用、一致性和高性能的要求。关于秒杀系统的设计思考

高性能。秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念其实是类似的：高读就尽量"少读"或"读少"，高写就数据拆分。本文将从动静分离、热点优化以及服务端性能优化 3 个方面展开。
一致性。秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，而且要保证准确性，显而易见是一个难题。如何做到既不多又不少？本文将从业界通用的几种减库存方案切入，讨论一致性设计的核心逻辑。
高可用。大型分布式系统在实际运行过程中面对的工况是非常复杂的，业务流量的突增、依赖服务的不稳定、应用自身的瓶颈、物理资源的损坏等方方面面都会对系统的运行带来大大小小的的冲击。如何保障应用在复杂工况环境下还能高效稳定运行，如何预防和面对突发问题，系统设计时应该从哪些方面着手？

六、秒杀系统设计策略

6.1 高性能设计

6.1.1 动静分离策略

大家可能会注意到，秒杀过程中你是不需要刷新整个页面的，只有时间在不停跳动。这是因为一般都会对大流量的秒杀系统做系统的静态化改造，即数据意义上的动静分离。动静分离三步走：

数据拆分
静态缓存
数据整合

6.1.1.1 数据拆分

动静分离的首要目的是将动态页面改造成适合缓存的静态页面。因此第一步就是分离出动态数据，主要从以下 2 个方面进行：

用户。用户身份信息包括登录状态以及登录画像等，相关要素可以单独拆分出来，通过动态请求进行获取；与之相关的广平推荐，如用户偏好、地域偏好等，同样可以通过异步方式进行加载。
时间。秒杀时间是由服务端统一管控的，可以通过动态请求进行获取。

这里你可以打开电商平台的一个秒杀页面，看看这个页面里都有哪些动静数据。

6.1.1.2 静态缓存

分离出动静态数据之后，第二步就是将静态数据进行合理的缓存，由此衍生出两个问题：

1、怎么缓存；

静态化改造的一个特点是直接缓存整个 HTTP 连接而不是仅仅缓存静态数据，如此一来，Web 代理服务器根据请求 URL，可以直接取出对应的响应体然后直接返回，响应过程无需重组 HTTP 协议，也无需解析 HTTP 请求头。而作为缓存键，URL唯一化是必不可少的，只是对于商品系统，URL 天然是可以基于商品 ID 来进行唯一标识的，比如淘宝的 https://item.taobao.com/item...

2、哪里缓存。

静态数据缓存到哪里呢？可以有三种方式：1、浏览器；2、CDN ；3、服务端。

浏览器当然是第一选择，但用户的浏览器是不可控的，主要体现在如果用户不主动刷新，系统很难主动地把消息推送给用户（注意，当讨论静态数据时，潜台词是 “相对不变”，言外之意是 “可能会变”），如此可能会导致用户端在很长一段时间内看到的信息都是错误的。对于秒杀系统，保证缓存可以在秒级时间内失效是不可或缺的。

服务端主要进行动态逻辑计算及加载，本身并不擅长处理大量连接，每个连接消耗内存较多，同时 Servlet 容器解析 HTTP 较慢，容易侵占逻辑计算资源；另外，静态数据下沉至此也会拉长请求路径。

因此通常将静态数据缓存在 CDN，其本身更擅长处理大并发的静态文件请求，既可以做到主动失效，又离用户尽可能近，同时规避 Java 语言层面的弱点。需要注意的是，上 CDN 有以下几个问题需要解决：

失效问题。任何一个缓存都应该是有时效的，尤其对于一个秒杀场景。所以，系统需要保证全国各地的 CDN 在秒级时间内失效掉缓存信息，这实际对 CDN 的失效系统要求是很高的
命中率问题。高命中是缓存系统最为核心的性能要求，不然缓存就失去了意义。如果将数据放到全国各地的 CDN ，势必会导致请求命中同一个缓存的可能性降低，那么命中率就成为一个问题

因此，将数据放到全国所有的 CDN 节点是不太现实的，失效问题、命中率问题都会面临比较大的挑战。更为可行的做法是选择若干 CDN 节点进行静态化改造，节点的选取通常需要满足以下几个条件：

临近访问量集中的地区
距离主站较远的地区
节点与主站间网络质量良好的地区

基于以上因素，选择 CDN 的二级缓存比较合适，因为二级缓存数量偏少，容量也更大，访问量相对集中，这样就可以较好解决缓存的失效问题以及命中率问题，是当前比较理想的一种 CDN 化方案。部署方式如下图所示：

6.1.1.3 数据整合

分离出动静态数据之后，前端如何组织数据页就是一个新的问题，主要在于动态数据的加载处理，通常有两种方案：ESI（Edge Side Includes）方案和 CSI（Client Side Include）方案。

ESI 方案：Web 代理服务器上请求动态数据，并将动态数据插入到静态页面中，用户看到页面时已经是一个完整的页面。这种方式对服务端性能要求高，但用户体验较好
CSI 方案：Web 代理服务器上只返回静态页面，前端单独发起一个异步 JS 请求动态数据。这种方式对服务端性能友好，但用户体验稍差

6.1.1.4 动静分离策略

动静分离对于性能的提升，抽象起来只有两点，一是数据要尽量少，以便减少没必要的请求，二是路径要尽量短，以便提高单次请求的效率。具体方法其实就是基于这个大方向进行的。

6.1.2 热点优化策略

热点分为热点操作和热点数据，以下分开进行讨论。零点刷新、零点下单、零点添加购物车等都属于热点操作。热点操作是用户的行为，不好改变，但可以做一些限制保护，比如用户频繁刷新页面时进行提示阻断。热点数据的处理三步走，一是热点识别，二是热点隔离，三是热点优化。

6.1.2.1 热点识别

热点数据分为静态热点和动态热点，具体如下：

静态热点：能够提前预测的热点数据。大促前夕，可以根据大促的行业特点、活动商家等纬度信息分析出热点商品，或者通过卖家报名的方式提前筛选；另外，还可以通过技术手段提前预测，例如对买家每天访问的商品进行大数据计算，然后统计出 TOP N 的商品，即可视为热点商品
动态热点：无法提前预测的热点数据。冷热数据往往是随实际业务场景发生交替变化的，尤其是如今直播卖货模式的兴起——带货商临时做一个广告，就有可能导致一件商品在短时间内被大量购买。由于此类商品日常访问较少，即使在缓存系统中一段时间后也会被逐出或过期掉，甚至在db中也是冷数据。瞬时流量的涌入，往往导致缓存被击穿，请求直接到达DB，引发DB压力过大。

因此秒杀系统需要实现热点数据的动态发现能力，一个常见的实现思路是：

异步采集交易链路各个环节的热点 Key 信息，如 Nginx采集访问URL或 Agent 采集热点日志（一些中间件本身已具备热点发现能力），提前识别潜在的热点数据
聚合分析热点数据，达到一定规则的热点数据，通过订阅分发推送到链路系统，各系统根据自身需求决定如何处理热点数据，或限流或缓存，从而实现热点保护。

需要注意的是：

热点数据采集最好采用异步方式，一方面不会影响业务的核心交易链路，一方面可以保证采集方式的通用性
热点发现最好做到秒级实时，这样动态发现才有意义，实际上也是对核心节点的数据采集和分析能力提出了较高的要求

6.1.2.2 热点隔离

热点数据识别出来之后，第一原则就是将热点数据隔离出来，不要让 1% 影响到另外的 99%，可以基于以下几个层次实现热点隔离：

业务隔离。秒杀作为一种营销活动，卖家需要单独报名，从技术上来说，系统可以提前对已知热点做缓存预热
系统隔离。系统隔离是运行时隔离，通过分组部署和另外 99% 进行分离，另外秒杀也可以申请单独的域名，入口层就让请求落到不同的集群中
数据隔离。秒杀数据作为热点数据，可以启用单独的缓存集群或者DB服务组，从而更好的实现横向或纵向能力扩展

当然，实现隔离还有很多种办法。比如，可以按照用户来区分，为不同的用户分配不同的 Cookie，入口层路由到不同的服务接口中；再比如，域名保持一致，但后端调用不同的服务接口；又或者在数据层给数据打标进行区分等等，这些措施的目的都是把已经识别的热点请求和普通请求区分开来。

6.1.2.3 热点优化

热点数据隔离之后，也就方便对这 1% 的请求做针对性的优化，方式无外乎两种：

缓存：热点缓存是最为有效的办法。如果热点数据做了动静分离，那么可以长期缓存静态数据
限流：流量限制更多是一种保护机制。需要注意的是，各服务要时刻关注请求是否触发限流并及时进行review

6.1.2.4 热点优化总结

数据的热点优化与动静分离是不一样的，热点优化是基于二八原则对数据进行了纵向拆分，以便进行针对性地处理。热点识别和隔离不仅对“秒杀”这个场景有意义，对其他的高性能分布式系统也非常有参考价值。

6.1.3 系统优化

对于一个软件系统，提高性能可以有很多种手段，如提升硬件水平、调优JVM 性能，这里主要关注代码层面的性能优化——

减少序列化：减少 Java 中的序列化操作可以很好的提升系统性能。序列化大部分是在 RPC 阶段发生，因此应该尽量减少 RPC 调用，一种可行的方案是将多个关联性较强的应用进行 “合并部署”，从而减少不同应用之间的 RPC 调用（微服务设计规范）
直接输出流数据：只要涉及字符串的I/O操作，无论是磁盘 I/O 还是网络 I/O，都比较耗费 CPU 资源，因为字符需要转换成字节，而这个转换又必须查表编码。所以对于常用数据，比如静态字符串，推荐提前编码成字节并缓存，具体到代码层面就是通过 OutputStream() 类函数从而减少数据的编码转换；另外，热点方法toString()不要直接调用ReflectionToString实现，推荐直接硬编码，并且只打印DO的基础要素和核心要素
裁剪日志异常堆栈：无论是外部系统异常还是应用本身异常，都会有堆栈打出，超大流量下，频繁的输出完整堆栈，只会加剧系统当前负载。可以通过日志配置文件控制异常堆栈输出的深度
去组件框架：极致优化要求下，可以去掉一些组件框架，比如去掉传统的 MVC 框架，直接使用 Servlet 处理请求。这样可以绕过一大堆复杂且用处不大的处理逻辑，节省毫秒级的时间，当然，需要合理评估你对框架的依赖程度

6.1.4 系统高性能设计总结

性能优化需要一个基准值，所以系统还需要做好应用基线，比如性能基线（何时性能突然下降）、成本基线（去年大促用了多少机器）、链路基线（核心流程发生了哪些变化），通过基线持续关注系统性能，促使系统在代码层面持续提升编码质量、业务层面及时下掉不合理调用、架构层面不断优化改进。

6.2 一致性设计

秒杀系统中，库存是个关键数据，卖不出去是个问题，超卖更是个问题。秒杀场景下的一致性问题，主要就是库存扣减的准确性问题。

6.2.1 减库存的方式

电商场景下的购买过程一般分为两步：下单和付款。“提交订单”即为下单，“支付订单”即为付款。基于此设定，减库存一般有以下几个方式：

下单减库存。买家下单后，扣减商品库存。下单减库存是最简单的减库存方式，也是控制最为精确的一种
付款减库存。买家下单后，并不立即扣减库存，而是等到付款后才真正扣减库存。但因为付款时才减库存，如果并发比较高，可能出现买家下单后付不了款的情况，因为商品已经被其他人买走了
预扣库存。这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 15 分钟），超过这段时间，库存自动释放，释放后其他买家可以购买

6.2.2 减库存的问题

6.2.2.1 下单减库存

优势：用户体验最好。下单减库存是最简单的减库存方式，也是控制最精确的一种。下单时可以直接通过数据库事务机制控制商品库存，所以一定不会出现已下单却付不了款的情况。

劣势：可能卖不出去。正常情况下，买家下单后付款概率很高，所以不会有太大问题。但有一种场景例外，就是当卖家参加某个促销活动时，竞争对手通过恶意下单的方式将该商品全部下单，导致库存清零，那么这就不能正常售卖了——要知道，恶意下单的人是不会真正付款的，这正是 “下单减库存” 的不足之处。

6.2.2.2 付款减库存

优势：一定实际售卖。“下单减库存” 可能导致恶意下单，从而影响卖家的商品销售， “付款减库存” 由于需要付出真金白银，可以有效避免。

劣势：用户体验较差。用户下单后，不一定会实际付款，假设有 100 件商品，就可能出现 200 人下单成功的情况，因为下单时不会减库存，所以也就可能出现下单成功数远远超过真正库存数的情况，这尤其会发生在大促的热门商品上。如此一来就会导致很多买家下单成功后却付不了款，购物体验自然是比较差的。

6.2.2.3 预扣库存

优势：缓解了以上两种方式的问题。预扣库存实际就是“下单减库存”和 “付款减库存”两种方式的结合，将两次操作进行了前后关联，下单时预扣库存，付款时释放库存。

劣势：并没有彻底解决以上问题。比如针对恶意下单的场景，虽然可以把有效付款时间设置为 10 分钟，但恶意买家完全可以在 10 分钟之后再次下单。

6.2.3 实际如何减库存

业界最为常见的是预扣库存。无论是外卖点餐还是电商购物，下单后一般都有个 “有效付款时间”，超过该时间订单自动释放，这就是典型的预扣库存方案。但如上所述，预扣库存还需要解决恶意下单的问题，保证商品卖的出去；另一方面，如何避免超卖，也是一个痛点。

卖的出去：恶意下单的解决方案主要还是结合安全和反作弊措施来制止。比如，识别频繁下单不付款的买家并进行打标，这样可以在打标买家下单时不减库存；再比如为大促商品设置单人最大购买件数，一人最多只能买 N 件商品；又或者对重复下单不付款的行为进行次数限制阻断等
避免超卖：库存超卖的情况实际分为两种。对于普通商品，秒杀只是一种大促手段，即使库存超卖，商家也可以通过补货来解决；而对于一些商品，秒杀作为一种营销手段，完全不允许库存为负，也就是在数据一致性上，需要保证大并发请求时数据库中的库存字段值不能为负，一般有多种方案：一是在通过事务来判断，即保证减后库存不能为负，否则就回滚；二是直接设置数据库字段类型为无符号整数，这样一旦库存为负就会在执行 SQL 时报错；三是使用 CASE WHEN 判断语句——

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

业务手段保证商品卖的出去，技术手段保证商品不会超卖，库存问题从来就不是简单的技术难题，解决问题的视角是多种多样的。

6.2.4 一致性性能的优化

库存是个关键数据，更是个热点数据。对系统来说，热点的实际影响就是 “高读” 和 “高写”，也是秒杀场景下最为核心的一个技术难题。

6.2.4.1 高并发读

秒杀场景解决高并发读问题，关键词是“分层校验”。即在读链路时，只进行不影响性能的检查操作，如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束、是否非法请求等，而不做一致性校验等容易引发瓶颈的检查操作；直到写链路时，才对库存做一致性检查，在数据层保证最终准确性。

因此，在分层校验设定下，系统可以采用分布式缓存甚至LocalCache来抵抗高并发读。即允许读场景下一定的脏数据，这样只会导致少量原本无库存的下单请求被误认为是有库存的，等到真正写数据时再保证最终一致性，由此做到高可用和一致性之间的平衡。

实际上，分层校验的核心思想是：不同层次尽可能过滤掉无效请求，只在“漏斗” 最末端进行有效处理，从而缩短系统瓶颈的影响路径。

6.2.4.2 高并发写

高并发写的优化方式，一种是更换DB选型，一种是优化DB性能，以下分别进行讨论。

6.2.4.3 更换DB选型

秒杀商品和普通商品的减库存是有差异的，核心区别在数据量级小、交易时间短，因此能否把秒杀减库存直接放到缓存系统中实现呢，也就是直接在一个带有持久化功能的缓存中进行减库存操作，比如 Redis？

如果减库存逻辑非常单一的话，比如没有复杂的 SKU 库存和总库存这种联动关系的话，个人认为是完全可以的。但如果有比较复杂的减库存逻辑，或者需要使用到事务，那就必须在数据库中完成减库存操作。

6.2.4.4 优化DB性能

库存数据落地到数据库实现其实是一行存储（MySQL），因此会有大量线程来竞争 InnoDB 行锁。但并发越高，等待线程就会越多，TPS 下降，RT 上升，吞吐量会受到严重影响——注意，这里假设数据库已基于上文【性能优化】完成数据隔离，以便于讨论聚焦。

解决并发锁的问题，有两种办法：

应用层排队。通过缓存加入集群分布式锁，从而控制集群对数据库同一行记录进行操作的并发度，同时也能控制单个商品占用数据库连接的数量，防止热点商品占用过多的数据库连接
数据层排队。应用层排队是有损性能的，数据层排队是最为理想的。业界中，阿里的数据库团队开发了针对InnoDB 层上的补丁程序（patch），可以基于DB层对单行记录做并发排队，从而实现秒杀场景下的定制优化——注意，排队和锁竞争是有区别的，如果熟悉 MySQL 的话，就会知道 InnoDB 内部的死锁检测，以及 MySQL Server 和 InnoDB 的切换都是比较消耗性能的。另外阿里的数据库团队还做了很多其他方面的优化，如 COMMIT_ON_SUCCESS 和 ROLLBACK_ON_FAIL 的补丁程序，通过在 SQL 里加入提示（hint），实现事务不需要等待实时提交，而是在数据执行完最后一条 SQL 后，直接根据 TARGET_AFFECT_ROW 的结果进行提交或回滚，减少网络等待的时间（毫秒级）。目前阿里已将包含这些补丁程序的 MySQL 开源：AliSQL

6.3 高可用设计

盯过秒杀流量监控的话，会发现它不是一条蜿蜒而起的曲线，而是一条挺拔的直线，这是因为秒杀请求高度集中于某一特定的时间点。这样一来就会造成一个特别高的零点峰值，而对资源的消耗也几乎是瞬时的。所以秒杀系统的可用性保护是不可或缺的。

6.3.1 流量削峰

对于秒杀的目标场景，最终能够抢到商品的人数是固定的，无论 100 人和 10000 人参加结果都是一样的，即有效请求额度是有限的。并发度越高，无效请求也就越多。但秒杀作为一种商业营销手段，活动开始之前是希望有更多的人来刷页面，只是真正开始后，秒杀请求不是越多越好。因此系统可以设计一些规则，人为的延缓秒杀请求，甚至可以过滤掉一些无效请求。

答题

早期秒杀只是简单的点击秒杀按钮，后来才增加了答题。为什么要增加答题呢？主要是通过提升购买的复杂度，达到两个目的：

防止作弊。早期秒杀器比较猖獗，存在恶意买家或竞争对手使用秒杀器扫货的情况，商家没有达到营销的目的，所以增加答题来进行限制
延缓请求。零点流量的起效时间是毫秒级的，答题可以人为拉长峰值下单的时长，由之前的 <1s 延长到 <10s。这个时间对于服务端非常重要，会大大减轻高峰期并发压力；另外，由于请求具有先后顺序，答题后置的请求到来时可能已经没有库存了，因此根本无法下单，此阶段落到数据层真正的写也就非常有限了

需要注意的是，答题除了做正确性验证，还需要对提交时间做验证，比如<1s 人为操作的可能性就很小，可以进一步防止机器答题的情况。答题目前已经使用的非常普遍了，本质是通过在入口层削减流量，从而让系统更好地支撑瞬时峰值。

排队

最为常见的削峰方案是使用消息队列，通过把同步的直接调用转换成异步的间接推送缓冲瞬时流量。除了消息队列，类似的排队方案还有很多，例如：

线程池加锁等待
本地内存蓄洪等待
本地文件序列化写，再顺序读

排队方式的弊端也是显而易见的，主要有两点：

请求积压。流量高峰如果长时间持续，达到了队列的水位上限，队列同样会被压垮，这样虽然保护了下游系统，但是和请求直接丢弃也没多大区别
用户体验。异步推送的实时性和有序性自然是比不上同步调用的，由此可能出现请求先发后至的情况，影响部分敏感用户的购物体验

排队本质是在业务层将一步操作转变成两步操作，从而起到缓冲的作用，但鉴于此种方式的弊端，最终还是要基于业务量级和秒杀场景做出妥协和平衡。

过滤

过滤的核心结构在于分层，通过在不同层次过滤掉无效请求，达到数据读写的精准触发。常见的过滤主要有以下几层：

1、读限流：对读请求做限流保护，将超出系统承载能力的请求过滤掉
2、读缓存：对读请求做数据缓存，将重复的请求过滤掉
3、写限流：对写请求做限流保护，将超出系统承载能力的请求过滤掉
4、写校验：对写请求做一致性校验，只保留最终的有效数据

过滤的核心目的是通过减少无效请求的数据IO保障有效请求的IO性能。

系统可以通过入口层的答题、业务层的排队、数据层的过滤达到流量削峰的目的，本质是在寻求商业诉求与架构性能之间的平衡。另外，新的削峰手段也层出不穷，以业务切入居多，比如零点大促时同步发放优惠券或发起抽奖活动，将一部分流量分散到其他系统，这样也能起到削峰的作用。

6.3.2 Plan B

当一个系统面临持续的高峰流量时，其实是很难单靠自身调整来恢复状态的，日常运维没有人能够预估所有情况，意外总是无法避免。尤其在秒杀这一场景下，为了保证系统的高可用，必须设计一个 Plan B 方案来进行兜底。高可用建设，其实是一个系统工程，贯穿在系统建设的整个生命周期。

具体来说，系统的高可用建设涉及架构阶段、编码阶段、测试阶段、发布阶段、运行阶段，以及故障发生时，逐一进行分析：

架构阶段：考虑系统的可扩展性和容错性，避免出现单点问题。例如多地单元化部署，即使某个IDC甚至地市出现故障，仍不会影响系统运转
编码阶段：保证代码的健壮性，例如RPC调用时，设置合理的超时退出机制，防止被其他系统拖垮，同时也要对无法预料的返回错误进行默认的处理
测试阶段：保证CI的覆盖度以及Sonar的容错率，对基础质量进行二次校验，并定期产出整体质量的趋势报告
发布阶段：系统部署最容易暴露错误，因此要有前置的checklist模版、中置的上下游周知机制以及后置的回滚机制
运行阶段：系统多数时间处于运行态，最重要的是运行时的实时监控，及时发现问题、准确报警并能提供详细数据，以便排查问题
故障发生：首要目标是及时止损，防止影响面扩大，然后定位原因、解决问题，最后恢复服务

对于日常运维而言，高可用更多是针对运行阶段而言的，此阶段需要额外进行加强建设，主要有以下几种手段：

预防：建立常态压测体系，定期对服务进行单点压测以及全链路压测，摸排水位
管控：做好线上运行的降级、限流和熔断保护。需要注意的是，无论是限流、降级还是熔断，对业务都是有损的，所以在进行操作前，一定要和上下游业务确认好再进行。就拿限流来说，哪些业务可以限、什么情况下限、限流时间多长、什么情况下进行恢复，都要和业务方反复确认
监控：建立性能基线，记录性能的变化趋势；建立报警体系，发现问题及时预警
恢复：遇到故障能够及时止损，并提供快速的数据订正工具，不一定要好，但一定要有

在系统建设的整个生命周期中，每个环节中都可能犯错，甚至有些环节犯的错，后面是无法弥补的或者成本极高的。所以高可用是一个系统工程，必须放到整个生命周期中进行全面考虑。同时，考虑到服务的增长性，高可用更需要长期规划并进行体系化建设。

6.3.3 高可用设计总结

高可用其实是在说 “稳定性”，稳定性是一个平时不重要，但出了问题就要命的事情，然而它的落地又是一个问题——平时业务发展良好，稳定性建设就会降级给业务让路。解决这个问题必须在组织上有所保障，比如让业务负责人背上稳定性绩效指标，同时在部门中建立稳定性建设小组，小组成员由每条线的核心力量兼任，绩效由稳定性负责人来打分，这样就可以把体系化的建设任务落实到具体的业务系统中了。