一：限流排队目的

约束客户端拜访用户的并发数量，阻拦超越系统负载的用户拜访，确保系统稳定运转，而且用户能够有效感知

二：架构阐明

2.1 架构图：

2.2 过程阐明

1. 用户恳求并发行列资历，资历项目维度划分（不同抢手项目的资历不共用）

1.  已存在，直接成功
2.  不存在，进行恳求
3.  并发行列满，测验恳求排队行列，已存在，直接成功并回来已有的行列数据
4.  并发行列满，排队行列不存在，进行恳求
5.  排队行列满，回来最终失利

2. task1 守时任务查看并发行列，查找已经过期的并发资历进行铲除
3. task2守时查看并发行列，当发现并发行列数量小于设置的总量，从排队行列队首获取数据主动恳求资历
4. 此架构阐明仅代表概念上的理解，不代表底层真实的设计结构

2.3 架构层级图

加购：

释义：

1. 资历: 代表成功进入到purchase room ，此刻用户拥有正常拜访系统的能力
2. 排队: 当purchase room 已满后，将进入到的一个排队结构，进入到此结构的用户将处于排队态，系统会主动在purchase room 有用户脱离的时分依照入队的顺序去恳求
3. 核心阻拦器:web层的大局阻拦，对每个恳求接口的用户验证其是否有资历

2.4 恳求资历技能流程图:

2.5 排队资历转化流程图:

资历清理场景:

1. 主动失效

   1. 前端监测，pc端用户在五分钟没有监测到touch事情，会主动铲除
   2. 前端监测，app端用户App后台运转 5 分钟，会主动铲除

2. 被动失效

   1. 用户未登陆，进入 purchase room 超越40 分钟
   2. 用户已登陆，进入purchase room 超越15 分钟
   3. 用户主动退出登陆
   4. 用户回到登陆页

三：流程阐明

3.1 流程图-其他项目排队流程

3.2 流程图-抢手项目排队流程图

• 用户开始拜访c端的页面

• 后端的一切接口均被阻拦，验证当时接口是否需求阻拦（如：登陆，退出等接口不需求阻拦），若不需求阻拦，直接经过，完毕

• 提取恳求中的参数数据，判断是否有项目id 数据，若没有，需求获取 <其他节目> 的资历(其他节目与抢手项目并列，各自拥有并发行列和排队行列，非抢手项目的即为其他项目);若有，取其项目id，验证用户是否有当时项目的并发资历

• 若当时用户已有当时项目的并发资历，阻拦逻辑经过（若当时用户已经有抢手项目的资历，再次拜访的接口 无项目id或为其他项目的项目id，也认定为有资历，即抢手项目的资历=抢手项目的资历 +其他节目的资历），完毕

• 若当时用户没有当时项目的并发资历，辨认当时是否有抢手项目

• 若当时没有抢手项目，后端将主动测验获取用户的并发资历，若成功，直接经过，完毕；若并发已满，测验进行排队，若排队成功，回来前端排队数据，前端进入排队页面，完毕；若排队行列满， 回来前端跳转 waiting room 的指令，前端将跳转waiting room，在此页面，页面主动依照admin 装备的时刻间隔测验进入排队行列

• 若当时有抢手项目，将提示前端跳转landing page ，显现 当时存在的抢手项目和其他节目，由用户自主选择进入，不主动给用户获取并发资历

• 用户在页面点击抢手项目或其他项目，若当时项目需求答题（只有抢手项目或许装备答题，其他项目无答题装备），用户需求答题正确，才能持续恳求并发资历，恳求并发资历成功，进入项目详情页；若并发已满，测验进行排队，若排队成功，进入排队页面；若排队行列满， 将跳转waiting room

留意：排队页面 和loading page 页面是两个。