- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
作者:来自 vivo 互联网服务器团队- Gao Meng 。
本文介绍了一种基于 sentinel 进行二次开发的动态限流解决方案,包括什么是动态限流、为什么需要引入动态限流、以及动态限流的实现原理.
随着互联网的发展及业务的增长,系统的流量和请求量越来越大,针对高并发系统,如果不对请求量进行限制,在流量突增时可能会导致系统崩溃或者服务不可用,影响用户体验。因此,系统需要引入限流来控制请求的流量,保证系统的可用性和稳定性。当前推荐业务使用公司vsentinel 限流工具,主要使用 QPS 限流和热点参数限流.
QPS 限流:对某个资源(通常为接口或方法,也可以自定义资源)的 QPS /并发数进行限流;热点参数限流:对某些具体的参数值进行限流,避免因为热点参数的过度访问导致服务宕机.
无论是 QPS 限流还是热点参数限流,都是对资源/参数的定量限流,即对某个资源/参数设置固定阈值,超过阈值则进行限流.
回到业务,游戏推荐系统作为游戏分发的平台,向公司内所有主要流量入口(包括游戏中心、应用商店、浏览器等)分发游戏、小游戏、内容和评论,具有大流量、高负载的业务特点。同时,游戏推荐系统对接的场景多(600+),单个性化接口有100+场景调用(场景可以理解为接口请求的一个基本请求参数)。当前的限流方案存在以下几个问题:
参数级别的限流,600+场景,无法做到每个场景精细化限流; 。
接口级别的限流,不会区分具体的场景,无法保证核心场景的可用性; 。
如果场景流量有变更,需要及时调整限流阈值,不易维护; 。
场景的流量会实时变化,无法做到根据流量变化的动态限流.
鉴于以上限流问题,推荐系统需要一个能够根据参数流量变化而动态调整限流阈值的精细化限流方案.
从配置方式上来看,动态限流和 QPS 限流、热点参数限流最大的不同之处在于,动态限流不是通过配置固定阈值进行限流,而是配置每个参数的优先级,根据参数的优先级动态调整限流阈值.
动态限流将资源和参数进行绑定,首先配置资源(一般是接口/方法)总的限流阈值,进而配置资源下具体参数的优先级,根据参数配置的优先级和实时流量,决定当前请求pass or block.
下图示例中,资源总的限流阈值为150,参数A、B、C、D的 QPS 均为100,且配置的参数优先级 A>B>C>D.
参数A优先级最高,且 QPS(A) = 100 < 限流阈值150,所以A的流量全部通过; 。
参数B优先级仅次于参数A,且 QPS(A) = 100 < 限流阈值150、QPS(A) + QPS(B)= 200 > 限流阈值150,所以参数B部分流量通过,pass : 50,block:50; 。
参数C和其它参数的优先级低于参数B,且 QPS(A) + QPS(B)= 200 > 限流阈值150,所以参数C和其它参数均被限流.
如果此时参数值A的 QPS 变为200,B、C的 QPS 仍为100,通过动态限流实现:A请求部分通过,B请求全部拦截,C请求全部拦截;根据各参数值流量的变化,动态适配各参数值通过/拦截的流量,从而实现根据参数值动态限流的效果.
总结:动态限流本质上是参数优先级限流,支持对参数值配置优先级,根据参数值的优先级进行动态流控。当流量超过阈值后,优先保证高优先级参数通过,拦截优先级低的参数请求.
由于动态限流是基于 sentinel 进行二次开发,且动态限流的实现算法是基于 sentinel QPS 限流的优化,这里首先介绍下 sentinel 实现原理和 sentinel QPS 限流的滑动窗口计数器限流算法.
sentinel 是阿里开源的一款面向分布式、多语言异构化服务架构的流量治理组件。主要以流量为切入点,从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。(官网描述) 。
sentinel 主要通过责任链模式实现不同模式的限流功能,责任链由一系列 ProcessorSlot 对象组成,每个 ProcessorSlot 对象负责不同的功能.
ProcessorSlot 对象可以分为两类:一类是辅助完成资源指标数据统计的 slot,一类是实现限流降级功能的 slot.
辅助资源指标数据统计的 ProcessorSlot:
NodeSelectorSlot:负责收集资源路径,并将调用路径树状存储,用于后续根据调用路径来限流降级; 。
ClusterBuilderSlot:负责存储资源的统计信息以及调用者信息,例如该资源的 RT、QPS、线程数等等,作为多维度限流、降级的依据; 。
StatisticSlot:负责实现指标数据统计,从多个维度(入口流量、调用者、资源)统计响应时间、并发线程数、处理失败数量、处理成功数量等指标信息.
实现限流降级功能的 slot:
ParamFlowSlot:用于根据请求参数进行限流(热点参数限流),例如根据某个参数的 QPS 进行限流,或者根据某个参数的值进行限流; 。
SystemSlot:用于根据系统负载情况进行限流,例如 CPU 使用率、内存使用率等.
AuthoritySlot:用于根据调用者身份进行限流,例如根据调用者的 IP 地址、Token 等信息进行限流.
FlowSlot:用于根据 QPS 进行限流,例如每秒最多只能处理多少请求.
DegradeSlot:用于实现熔断降级功能,例如当某个资源出现异常时,可以将其熔断并降级处理.
除了上述原生 ProcessorSlot,sentinel 还支持 SPI 插件功能,通过实现 ProcessorSlot 接口自定义 slot,从而能实现个性化功能拓展。动态限流正是基于 sentinel SPI 插件方式实现.
sentinel 的 QPS 限流采用滑动窗口计数器算法,下面我们简单介绍下这个算法原理.
首先介绍一下计数器算法.
计数器算法:维护一个固定单位时间的计数器来统计请求数,在计数小于限流阈值时通过请求,计数到达限流阈值后拦截请求,直到下一个单位时间再重新计数。假设资源限制 1 秒内的访问次数不能超过 100 次.
维护一个计数器,每次有新的请求过来,计数器加 1; 。
收到新请求后,如果计数器的值小于限流值,并且与上一次请求的时间间隔还在 1秒内,允许请求通过,否则拒绝请求;如果超出了时间间隔,要将计数器清零.
计数器算法存在一个问题:窗口切换时可能会出现流量突刺(最高2倍)。极端情况下,假设每秒限流100,在第1s和第2s分别通100个请求,且第1s的请求集中在后半段,第2s的请求集中在前半段,那么其实在500ms到1500ms这个1s的时间段,通过了200个请求.
为了解决这个问题,引入了基于滑动窗口的计数器算法.
滑动窗口计数器算法是计数器算法的改进,解决了固定窗口的流量突刺问题。算法原理:
将时间划分为细粒度的区间,每个区间维持一个计数器,每进入一个请求则将计数器加1; 。
多个区间组成一个时间窗口,每到一个区间时间后,则抛弃最老的一个区间,纳入新区间; 。
若当前窗口的区间计数器总和超过设定的限制数量,则本窗口内的后续请求都被丢弃.
滑动窗口本质上是固定窗口更细粒度的限流,将单位时间划分多个窗口,划分的窗口越多,数据越精确.
动态限流是基于 sentinel 的二次开发,具体实现流程和 sentinel 的 QPS 限流类似,可以归纳为三步:数据统计、规则管理、流量校验.
数据统计:统计资源(接口/方法/参数)的流量; 。
规则管理:管理限流规则,维护资源的限流阈值及参数值优先级; 。
流量校验:对比统计到的流量和对应的限流规则,决定当前请求 pass or block.
动态限流的数据统计同 sentinel 流量控制模块一样,使用滑动窗口计数器算法统计当前的流量.
具体来讲,sentinel 流量控制中的数据统计,是将1s的时间窗细分为多个窗口,按窗口维度统计资源信息,包括请求总数、成功总数、异常总数、总耗时、最小耗时、最大耗时等.
动态限流的数据统计,同样是将1s的时间窗细分为多个窗口,不同的是窗口的统计维度是各个参数值通过的总流量.
具体实现上,每个资源有唯一的 bucket,bucket 内维护一个固定数量的滑动窗口,窗口中的 value 是一个 hash 结构,hash key 为限流参数的参数值,value 为参数值在当前时间窗口的请求量.
参数值流量统计流程:
系统收到请求后,首先找到当前资源的 bucket; 。
再根据当前时间戳对 bucket 内的窗口数量取余,定位到当前时间窗; 。
当前时间窗内参数值的请求量+1.
规则管理模块:配置和管理限流规则.
限流规则通过zk实现从后台到端上的同步。后台配置好限流规则后,将限流规则同步到zk;客户端监听zk消息变更,同步最新的限流规则.
对于动态限流而言,参数的限流阈值不是固定的,只有参数优先级的概念,所以校验的第一步是要找到限流阈值优先级的临界点.
如果参数优先级临界点已知,只需要判断流量参数的优先级大小。如果请求的优先级高于阈值参数的优先级,pass;反之,如果请求的优先级低于阈值参数的优先级,block;优先级相等,按接口阈值限流.
那么如何确认当前限流的优先级呢?
当前限流阈值配置一般为秒级别的限流,细分滑动窗口,就是将1s的窗口划分为N个更小的时间窗,只要N足够大,就可以将前N-1个窗口已经统计到的参数流量近似当做这一秒的流量,进而就可以计算出临界参数的优先级。具体来讲,每一个窗口中都记录了参数的请求数量,所以只要将前N-1个窗口的流量累加,就可以得到各个参数在当前这1s内的总请求量;之后按照参数的优先级从高到低,依次累加流量并与阈值比较,如果累加到某个参数时大于限流阈值,则这个参数对应的优先级即为限流阈值优先级的临界点.
上面分析都是基于最理想情况:将1s的窗口无限细分。考虑到滑动窗口粒度越小,统计数据计算的越准确,但同时占用的资源也越多,计算越复杂,时延也越高,所以在实际应用中,1s的窗口不可能无限细分,是否有更好的优化方案呢?
上面是将1s的窗口划分为N个更小的时间窗,将前N-1个窗口近似看成1s,利用前N-1个窗口的统计数据,来判断当前窗口是否需要限流.
N-1→ N → 1s,N越大误差越小,反之N越小误差就越大,为了弥补N大小引起的计算误差,将统计窗口朝前挪一个,即用最近1s已有的统计数据,来判断当前窗口是否需要限流.
换一种说法:用最近1s已有的统计数据计算临界点参数,预测当前窗口的请求是否需要限流。如果当前请求参数的优先级高于临界点参数,pass;低于临界点参数,block;等于临界点参数,部分通过.
综上:动态限流采用细分窗口+动态预测的方法计算当前限流参数的优先级阈值.
举例说明:对方法 method(String param) 配置动态限流,限流阈值为120,配置 param 具体参数值的优先级为A→ 1, B→ 2, C→ 3(按重要程度划分 A > B > C);假设窗口大小为100ms,即1s细分为10个滑动窗口。每次开始新窗口流量计数时,先统计前10个窗口中各参数的请求量,继而按照优先级从高到低进行累加,确认优先级阈值;比如统计到前10个窗口中参数A, B, C的请求量均为100,因为A的流量100 < 阈值120,A + B的流量200 > 阈值120,所以此时临界参数为B;窗口接收到新请求后,比较请求参数和临界参数的优先级,比如参数A的请求,因为A的优先级高于B, pass;参数B的临界参数请求,允许部分流量通过;参数C的优先级低于临界参数,block.
经过上面的分析可知,通过滑动窗口+动态预测的方案就可以找到临界点参数,进而根据参数优先级决定当前请求 pass or block。但是在实际时间窗和统计时间窗之间,有一个时间 gap,在这个时间窗内的流量计算有一定的滞后性,比如上面的例子,在新窗口中A的请求全部 pass,如果此时A的流量突刺到1000,那么总体通过的流量就会超过阈值,如下图所示.
由上图可知,在流量突增的一个时间窗内,当前方案通过的流量会有突刺,为了解决流量突增带来的突刺问题,使用 double check 进行校验;check1 为细分窗口+动态预测方案,通过 check1 的流量可能会有突刺;增加 check2 对资源进行限流,保证被保护资源通过的总流量不超过阈值.
double check 流量在应对流量突增时的流量情况:
复用 sentinel 责任链+ SPI 架构,使用独立 SDK 打包方式嵌入动态限流模板,不影响原 sentinel 处理流程,按需引入.
动态限流配置生效后,可通过监控查看各配置参数通过/拒绝的请求量,实现限流功能的可视化.
如上图所示,配置某个资源的单机限流阈值为50,这一秒内的总请求量为74,通过50个请求,拒绝14个请求(其中配置限流的参数 xx.scene.priority1、xx.scene.priority2、xx.scene.priority3 在这一秒通过的请求数量分别为2个、16个、2个;其它参数通过30个请求,拒绝14个请求).
解释:在这一秒内,配置的三个参数总请求量为20(2+16+2),小于阈值50,全部通过;其它参数总流量为44,这一秒的总请求量为64(20+44),大于限流阈值50,所以其它参数共通过30个请求,拒绝14个请求.
本文介绍了一种基于 sentinel 进行二次开发的动态限流解决方案,提供更细粒度、能够根据流量动态调整限流阈值的参数级限流方法,是对 sentinel 限流功能的补充和拓展.
对比 sentinel 的 QPS 限流,动态限流方案提供了更细粒度的参数级别的限流; 。
对比 sentinel 的热点参数限流,热点参数限流是对参数的定量限流,适用于参数大流量场景,比如对某个频繁请求的参数(id/商品)进行限流;动态限流根据配置的参数优先级(重要程度)进行限流,限流的阈值参数会根据资源的流量动态调整,pass 高优参数,block 低优参数,限流重点是“保核心”.
综上,动态限流是对 sentinel 限流功能的补充,用户可以结合具体场景配置不同的限流方案.
最后此篇关于游戏推荐业务中基于sentinel的动态限流实践的文章就讲到这里了,如果你想了解更多关于游戏推荐业务中基于sentinel的动态限流实践的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
这也不是一篇非常详细的源码领读,源码细节还需你自己仔细咀嚼 这只是我在改了些sentinel bug后,梳理的脉络,主要是脉络。看完后对Sentinel的源码模块划分和大致交互有个整体印象。 从而
还有其他类似的问题,但我想将其归结为最基本的问题。 我正在运行一个 .NET 应用程序 (C#) 并尝试连接并监视一组运行哨兵 ( 3x 哨兵监控 1 个主站和 2 个从站)。它们在 linux 机器
我们有 2 个运行 HA 应用程序的应用程序/Web 服务器,我们需要设置具有高可用性/复制功能的 Redis 以支持我们的应用程序。 考虑到 3 个节点的最低哨兵设置要求。 我们计划准备第一个应用程
我想知道是否可以将 Azure AD 用户配置文件详细信息(使用位置、国家或地区、办公室)获取到 azure Sentinel 日志中? Kusto 查询会是什么? 最佳答案 此功能将作为 Azure
Sentinel Dashboard限流规则保存 sentinel在限流规则配置方面提供了可视化页面 sentinel dashboard,源码可从github下载,请自行搜索,此处不提供下载链接
概念 何为热点?热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据,并对其访问进行限制。比如: 商品 ID 为参数,统计一段时间内最常购买的商品 ID 并进行限制
概述 除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。由于调用关系的复杂性,如果调用链路中的某个资源不稳定,最终会导致请求发生堆积。Sentinel 熔断降级会在调
前言 在上一节中我们知道Sentinel 支持以下几种规则:流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则 和 热点参数规则。 Sentinel 的所有规则都可以在内存态中动态地查询及修改
在之前使用Nacos持久化规则的文档中,最后发现只能使用Nacos推送配置到控制台,那么怎么实现控制台和Nacos的双向同步呢? 这里不直接提供解决方案,我们还是先分析下控制台的源码。 下面我们分
化整为零 我们已经知道了Slot是从第一个往后一直传递到最后一个的,且当信息传递到StatisticSlot时,这里就开始进行统计了,统计的结果又会被后续的Slot所采用,作为规则校验的依据。我们先
Sentinel简介 Sentinel 是阿里中间件团队开源的,面向分布式服务架构的轻量级高可用流量控制组件,主要以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定
之前遗留问题 之前我们集成了Nacos,实现了推送规则到客户端,但是控制台添加的规则不能持久化到Naocs中,这时需要对控制台源码进行改造。 先来回顾下默认添加流控规则的执行流程: 1、 控
Sentinel 中有很多比较重要的概念,我们要了解一个框架,首先要对框架中重要的概念实体进行分析,本文我将跟大家一起来分析一下 Sentinel 中非常重要的几个概念。 Resource Res
通过sentinel 的控制台,我们可以对规则进行查询和修改,也可以查看到实时监控,机器列表等信息,所以我们需要对 sentinel 的控制台做个完整的了解。 启动控制台 从github上下载源码
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件,主要以流量为切入点,从流量控制、熔断降级、系统自适应保护等多个维度来帮助您保障微服务的稳定
控制台 控制台主要的处理类是 FlowControllerV1 。 @RestController @RequestMapping(value = "/v1/flow") pu
项目结构 将Sentinel的源码fork到自己的github库中,接着把源码clone到本地,然后开始源码阅读之旅吧。 首先我们看一下Sentinel项目的整个结构: sentine
雪崩效应 雪崩 一种自然现象,当山坡积雪内部的内聚力抗拒不了它所受到的重力拉引时,便向下滑动,引起大量雪体崩塌。 雪崩效应广泛应用于各种领域,比如密码学术语、管理学、商业等。 服务雪崩 在软件
实时监控 集成控制台后,当有请求时,实时监控页面会显示当前服务各个接口的访问信息,以图表的形式展示给用户,包含访问时间、通过 QPS、拒绝QPS、响应时间(ms)等信息。 簇点链路 列表:用
实时监控 Sentinel 提供对所有资源的实时监控,我们可以通过控制台查看。 可以很清楚的看到当前QPS流量趋势。 监控API 簇点监控 获取簇点列表 API: GET /cluste
我是一名优秀的程序员,十分优秀!