文章目录

• 一、限流排队目的
• 二、架构说明
• • 2.1 架构图：
  • 2.2 步骤说明
  • 2.3 架构层级图
  • 2.4 申请资格技术流程图:
  • 2.5 排队资格转化流程图:
• 三、流程说明
• • 3.1 流程图-其他项目排队流程
  • 3.2 流程图-热门项目排队流程图

一、限流排队目的

限制客户端访问用户的并发数量，拦截超过系统负载的用户访问，保证系统稳定运行，并且用户能够有效感知。

二、架构说明

2.1 架构图：

2.2 步骤说明

1. 用户申请并发队列资格，资格项目维度划分（不同热门项目的资格不共用）

• 已存在，直接成功
• 不存在，进行申请
• 并发队列满，尝试申请排队队列，已存在，直接成功并返回已有的队列数据
• 并发队列满，排队队列不存在，进行申请
• 排队队列满，返回最终失败

2. task1 定时任务检查并发队列，查找已经过期的并发资格进行清除
3. task2定时检查并发队列，当发现并发队列数量小于设置的总量，从排队队列队首获取数据自动申请资格
4. 此架构说明仅代表概念上的理解，不代表底层真实的设计结构

2.3 架构层级图

加购：

释义：

1. 资格: 代表成功进入到purchase room ，此时用户拥有正常访问系统的能力
2. 排队: 当purchase room 已满后，将进入到的一个排队结构，进入到此结构的用户将处于排队态，系统会自动在purchase room 有用户离开的时候按照入队的顺序去申请
3. 核心拦截器:web层的全局拦截，对每个请求接口的用户验证其是否有资格

2.4 申请资格技术流程图:

2.5 排队资格转化流程图:

资格清理场景:

1. 主动失效

• 前端监测，pc端用户在五分钟没有监测到touch事件，会自动清除
• 前端监测，app端用户 App后台运行 5 分钟，会自动清除

2. 被动失效

• 用户未登陆，进入 purchase room 超过40 分钟
• 用户已登陆，进入purchase room 超过15 分钟
• 用户主动退出登陆
• 用户回到登陆页

三、流程说明

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

3.2 流程图-热门项目排队流程图

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

• 后端的所有接口均被拦截，验证当前接口是否需要拦截（如：登陆，退出等接口不需要拦截），若不需要拦截，直接通过，结束

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

• 若当前用户已有当前项目的并发资格，拦截逻辑通过（若当前用户已经有热门项目的资格，再次访问的接口 无项目id或为其他项目的项目id，也认定为有资格，即热门项目的资格=热门项目的资格 +其他节目的资格），结束

• 若当前用户没有当前项目的并发资格，识别当前是否有热门项目

若当前没有热门项目，后端将自动尝试获取用户的并发资格，若成功，直接通过，结束；若并发已满，尝试进行排队，若排队成功，返回前端排队数据，前端进入排队页面，结束；若排队队列满， 返回前端跳转 waiting room 的指令，前端将跳转waiting room，在此页面，页面自动按照admin 配置的时间间隔尝试进入排队队列

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

• 用户在页面点击热门项目或其他项目，若当前项目需要答题（只有热门项目可能配置答题，其他项目无答题配置），用户需要答题正确，才能继续申请并发资格，申请并发资格成功，进入项目详情页；若并发已满，尝试进行排队，若排队成功，进入排队页面；若排队队列满， 将跳转waiting room

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