Java架构-看完这篇，你也能设计一个高性能的“秒杀”系统

从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统需要进行哪些关注，就是本文讨论的话题。

前言

秒杀大家都不陌生。自2011年首次出现以来，无论是双十一购物还是 12306 抢票，秒杀场景已随处可见。简单来说，秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。

从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统需要进行哪些关注，就是本文讨论的话题。

整体思考

首先从高维度出发，整体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。关于秒杀系统的设计思考，本文即基于此 3 层依次推进，简述如下：

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

1 动静分离

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

1.1 数据拆分

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

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

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

1.2.1 怎么缓存

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

1.2.2 哪里缓存

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

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

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

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

失效问题。任何一个缓存都应该是有时效的，尤其对于一个秒杀场景。所以，系统需要保证全国各地的 CDN 在秒级时间内失效掉缓存信息，这实际对 CDN 的失效系统要求是很高的
命中率问题。高命中是缓存系统最为核心的性能要求，不然缓存就失去了意义。如果将数据放到全国各地的 CDN ，势必会导致请求命中同一个缓存的可能性降低，那么命中率就成为一个问题
因此，将数据放到全国所有的 CDN 节点是不太现实的，失效问题、命中率问题都会面临比较大的挑战。更为可行的做法是选择若干 CDN 节点进行静态化改造，节点的选取通常需要满足以下几个条件：

临近访问量集中的地区
距离主站较远的地区
节点与主站间网络质量良好的地区
基于以上因素，选择 CDN 的二级缓存比较合适，因为二级缓存数量偏少，容量也更大，访问量相对集中，这样就可以较好解决缓存的失效问题以及命中率问题，是当前比较理想的一种 CDN 化方案。部署方式如下图所示：

Java架构-看完这篇，你也能设计一个高性能的“秒杀”系统
1.3 数据整合

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

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

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

2 热点优化

热点分为热点操作和热点数据，以下分开进行讨论。

2.1 热点操作

零点刷新、零点下单、零点添加购物车等都属于热点操作。热点操作是用户的行为，不好改变，但可以做一些限制保护，比如用户频繁刷新页面时进行提示阻断。

2.2 热点数据

热点数据的处理三步走，一是热点识别，二是热点隔离，三是热点优化。

2.2.1 热点识别

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

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

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

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

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

业务隔离。秒杀作为一种营销活动，卖家需要单独报名，从技术上来说，系统可以提前对已知热点做缓存预热
系统隔离。系统隔离是运行时隔离，通过分组部署和另外 99% 进行分离，另外秒杀也可以申请单独的域名，入口层就让请求落到不同的集群中
数据隔离。秒杀数据作为热点数据，可以启用单独的缓存集群或者DB服务组，从而更好的实现横向或纵向能力扩展
当然，实现隔离还有很多种办法。比如，可以按照用户来区分，为不同的用户分配不同的 Cookie，入口层路由到不同的服务接口中；再比如，域名保持一致，但后端调用不同的服务接口；又或者在数据层给数据打标进行区分等等，这些措施的目的都是把已经识别的热点请求和普通请求区分开来。

2.2.3 热点优化

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

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

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

3 系统优化

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

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

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

一致性

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

1 减库存的方式

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

下单减库存。买家下单后，扣减商品库存。下单减库存是最简单的减库存方式，也是控制最为精确的一种
付款减库存。买家下单后，并不立即扣减库存，而是等到付款后才真正扣减库存。但因为付款时才减库存，如果并发比较高，可能出现买家下单后付不了款的情况，因为商品已经被其他人买走了
预扣库存。这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 15 分钟），超过这段时间，库存自动释放，释放后其他买家可以购买
能够看到，减库存方式是基于购物过程的多阶段进行划分的，但无论是在下单阶段还是付款阶段，都会存在一些问题，下面进行具体分析。

2 减库存的问题

2.1 下单减库存

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

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

2.2 付款减库存

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

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

2.3 预扣库存

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

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

2.4 小结

减库存的问题主要体现在用户体验和商业诉求两方面，其本质原因在于购物过程存在两步甚至多步操作，在不同阶段减库存，容易存在被恶意利用的漏洞。

个人总结

一个秒杀系统的设计，可以根据不同级别的流量，由简单到复杂打造出不同的架构，本质是各方面的取舍和权衡。当然，你可能注意到，本文并没有涉及具体的选型方案，因为这些对于架构来说并不重要，作为架构师，应该时刻提醒自己主线是什么。