一、限流排队目的

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

二、架构说明

2.1 架构图：

2.2 步骤说明

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

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

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

2.3 架构层级图

加购：

释义：

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

2.4 申请资格技术流程图:

2.5 排队资格转化流程图:

资格清理场景:

主动失效

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

被动失效

用户未登陆，进入 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 页面是两个。

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/132187.html