新增秒杀设计

Architecture.md

@@ -4094,6 +4094,31 @@ DDoS 攻击，英文全称是 Distributed Denial of Service，谷歌翻译过来
 
 # 秒杀商品
 
+**设计难点**：并发量大，应用、数据库都承受不了。另外难控制超卖。
+
+**设计要点**：
+
+- 将请求尽量拦截在系统上游，html尽量静态化，部署到cdn上面。按钮及时设置为不可用，禁止用户重复提交请求
+- 设置页面缓存，针对同一个页面和uid一段时间内返回缓存页面
+- 数据用缓存抗，不直接落到数据库
+- 读数据的时候不做强一致性教研，写数据的时候再做
+- 在每台物理机上也缓存商品信息等等变动不大的相关的数据
+- 像商品中的标题和描述这些本身不变的会在秒杀开始之前全量推送到秒杀机器上并一直缓存直到秒杀结束
+- 像库存这种动态数据会采用被动失效的方式缓存一定时间（一般是数秒），失效后再去Tair缓存拉取最新的数据
+- 如果允许的话，用异步的模式，等缓存都落库之后再返回结果
+- 如果允许的话，增加答题教研等验证措施
+
+![秒杀系统](images/Architecture/秒杀系统.png)
+
+**其它业务和技术保障措施**：
+
+- **业务隔离**。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热
+- **系统隔离**。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外 99% 分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中
+- **数据隔离**。秒杀所调用的数据大部分都是热数据，比如会启用单独 cache 集群或 MySQL 数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%
+- **缓存数据库高可用**。主要流量都落在缓存数据库上，需针对缓存数据库的高可用作保障。研究缓存穿透、雪崩等等问题
+
+
+
 ## 瞬时高并发
 
 一般在`秒杀时间点`（比如：12点）前几分钟，用户并发量才真正突增，达到秒杀时间点时，并发量会达到顶峰。但由于这类活动是大量用户抢少量商品的场景，必定会出现`狼多肉少`的情况，所以其实绝大部分用户秒杀会失败，只有极少部分用户能够成功。正常情况下，大部分用户会收到商品已经抢完的提醒，收到该提醒后，他们大概率不会在那个活动页面停留了，如此一来，用户并发量又会急剧下降。所以这个峰值持续的时间其实是非常短的，这样就会出现瞬时高并发的情况，下面用一张图直观的感受一下流量的变化：
@@ -4585,33 +4610,6 @@ return false;
 
 
 
-## 秒杀系统
-
-**设计难点**：并发量大，应用、数据库都承受不了。另外难控制超卖。
-
-**设计要点**：
-
-- 将请求尽量拦截在系统上游，html尽量静态化，部署到cdn上面。按钮及时设置为不可用，禁止用户重复提交请求
-- 设置页面缓存，针对同一个页面和uid一段时间内返回缓存页面
-- 数据用缓存抗，不直接落到数据库
-- 读数据的时候不做强一致性教研，写数据的时候再做
-- 在每台物理机上也缓存商品信息等等变动不大的相关的数据
-- 像商品中的标题和描述这些本身不变的会在秒杀开始之前全量推送到秒杀机器上并一直缓存直到秒杀结束
-- 像库存这种动态数据会采用被动失效的方式缓存一定时间（一般是数秒），失效后再去Tair缓存拉取最新的数据
-- 如果允许的话，用异步的模式，等缓存都落库之后再返回结果
-- 如果允许的话，增加答题教研等验证措施
-
-![秒杀系统](images/Architecture/秒杀系统.png)
-
-**其它业务和技术保障措施**：
-
-- **业务隔离**。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热
-- **系统隔离**。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外 99% 分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中
-- **数据隔离**。秒杀所调用的数据大部分都是热数据，比如会启用单独 cache 集群或 MySQL 数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%
-- **缓存数据库高可用**。主要流量都落在缓存数据库上，需针对缓存数据库的高可用作保障。研究缓存穿透、雪崩等等问题
-
-
-
 ## 红包系统
 
 红包系统其实很像秒杀系统，只不过同一个秒杀的总量不大，但是全局的并发量非常大，如春晚可能几百万人同时抢红包。