如何设计一个秒杀系统-极客课程笔记

最近学习的一门课程，记录下学习笔记

感兴趣的朋友可以去购买，课程地址：如何设计一个秒杀系统 (geekbang.org)

本文会一直更新修改，因为一天看一点学一点，嘻嘻，：)

开篇词 | 秒杀系统架构设计都有哪些关键点？

从技术角度上看“稳、准、快”，就对应了我们架构上的高可用、一致性和高性能的要求：

• 高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。本专栏将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这 4 个方面重点介绍。

• 一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，我将用一篇文章来专门讲解如何设计秒杀减库存方案。

• 高可用。 虽然我介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，我们还要设计一个 PlanB 来兜底，以便在最坏情况发生时仍然能够从容应对。专栏的最后，我将带你思考可以从哪些环节来设计兜底方案。

01 | 设计秒杀系统时应该注意的5个架构原则

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

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

数据要尽量少、请求数要尽量少、路径要尽量短、依赖要尽量少，以及不要有单点。

1. 数据要尽量少。 所谓“数据要尽量少”，首先是指用户请求的数据能少就少。请求的数据包括上传给系统的数据和系统返回给用户的数据(通常就是网页)。减少传输的数据量可以显著减少 CPU 的使用。例如，我们可以简化秒杀页面的大小，去掉不必要的页面装修效果，数据库打交道越少越好，数据越简单、越小则越好，等等。

2. 请求数要尽量少。 页面依赖的 CSS/JavaScript、图片，以及 Ajax 请求等等都定义为“额外请求”，这些额外请求应该尽量少。

3. 路径要尽量短。 所谓“路径”，就是用户发出请求到返回数据这个过程中，需求经过的中间的节点数。

4. 依赖要尽量少 所谓依赖，指的是要完成一次用户请求必须依赖的系统或者服务，这里的依赖指的是强依赖。\ 注意，0 级系统要尽量减少对 1 级系统的强依赖，防止重要的系统被不重要的系统拖垮。例如支付系统是 0 级系统，而优惠券是 1 级系统的话，在极端情况下可以把优惠券给降级，防止支付系统被优惠券这个 1 级系统给拖垮。

5. 不要有单点 系统中的单点可以说是系统架构上的一个大忌，因为单点意味着没有备份，风险不可控，我们设计分布式系统最重要的原则就是“消除单点”。\ 那如何避免单点呢？我认为关键点是避免将服务的状态和机器绑定，即把服务无状态化，这样服务就可以在机器中随意移动。

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

不同场景下的不同架构案例

请求量低于1w/s

如果你想快速搭建一个简单的秒杀系统，只需要把你的商品购买页面增加一个“定时上架”功能，仅在秒杀开始时才让用户看到购买按钮，当商品的库存卖完了也就结束了。这就是当时第一个版本的秒杀系统实现方式。

请求量1w/s~10w/s

1. 把秒杀系统独立出来单独打造一个系统，这样可以有针对性地做优化，例如这个独立出来的系统就减少了店铺装修的功能，减少了页面的复杂度；
2. 在系统部署上也独立做一个机器集群，这样秒杀的大流量就不会影响到正常的商品购买集群的机器负载；
3. 将热点数据(如库存数据)单独放到一个缓存系统中，以提高“读性能”；
4. 增加秒杀答题，防止有秒杀器抢单。

请求量超过100w/s

1. 对页面进行彻底的动静分离，使得用户秒杀时不需要刷新整个页面，而只需要点击抢宝按钮，借此把页面刷新的数据降到最少；
2. 在服务端对秒杀商品进行本地缓存，不需要再调用依赖系统的后台服务获取数据，甚至不需要去公共的缓存集群中查询数据，这样不仅可以减少系统调用，而且能够避免压垮公共缓存集群。
3. 增加系统限流保护，防止最坏情况发生。

02 | 如何才能做好动静分离？有哪些方案可选？