服务器限制流量(服务器限流怎么办)

服务器限制流量(服务器限流怎么办)

扫码添加渲大师小管家,免费领取渲染插件、素材、模型、教程合集大礼包!

服务限流场景

在高并发大流量系统中,由于并发大造成服务资源不足,负载过高,进而引发致一系列问题,这里的流量一般都是突发性的,由于系统准备不足,很难短期扩容来应对,进行限流是最常用的手段,所以说限流也是服务稳定性治理重要的手段。

限流可能发生在多个层面:

用户网络层:突发的流量场景如热点事件流量(秒杀事件、热门抢购,微博热搜),恶意刷流,竞对爬虫等。

内部应用层:上游服务的异常调用,脚本异常请求,失败重试策略造成流量突发。

实现限流方案

常用的限流方法主要有三种:计数器算法,漏斗桶算法,令牌桶算法。

1.计算器限流

1.1实现原理

设计限流条件,如根据用户id/商户id/IP/UUID+请求url作为限流对象,对限流对象的每次流量访问进行全局计数,设置限流阈值(1000次/秒,10000/分钟),如果统计时间窗口期内达到阈值就进行限流。

对单机限流来说,使用全局内存计数即可,但对分布式系统需要有一个公共存储计数,redis是最佳存储方案,且redis的incr能保障原子性操作。

1.2代码实现

//@paramkeystringobjectforratelimitsuchasuid/ip+url//@paramfillIntervaltime.Durationsuchas1*time.Second//@paramlimitNummaxint64allowednumberperfillInterval//@returnwhetherreachratelimit,falsemeansreach.funcfixedWindowRateLimit(keystring,fillIntervaltime.Duration,limitNumint64)bool{//currentticktimewindowtick:=int64(time.Now.Unix/int64(fillInterval.Seconds))currentKey:=fmt.Sprintf("%s_%d_%d_%d",key,fillInterval,limitNum,tick)

startCount:=0_,err:=client.SetNX(currentKey,startCount,fillInterval).Resultiferr!=nil{panic(err)}//numberincurrenttimewindowquantum,err:=client.Incr(currentKey).Resultiferr!=nil{panic(err)}ifquantum>limitNum{returnfalse}returntrue}

完整代码参见:

https://github.com/skyhackvip/ratelimit/blob/master/fixedwindow.go

测试代码:

functest1{fori:=0;i<10;i++{gofunc{rs:=fixedWindowRateLimit("test1",1*time.Second,5)fmt.Println("resultis:",rs)}}}

测试执行结果:

服务器限制流量(服务器限流怎么办)

根据执行结果可以看到,1秒中有10个请求,只有5个通过,另5个被限流返回false。

这个代码实现的是固定时间窗口,有一个问题,当流量在上一个时间窗口下半段和下一个时间窗口上半段集中爆发,那么这两段组成的时间窗口内流量是会超过limit限制的。

测试代码如下,拉长时间窗口为1分钟,1分钟限流5个,前30s没流量,之后每10s一个请求:

functest2{fillInteval:=1*time.MinutevarlimitNumint64=5waitTime:=30fmt.Printf("timerangefrom0to%d\n",waitTime)time.Sleep(time.Duration(waitTime)*time.Second)fori:=0;i<10;i++{fmt.Printf("timerangefrom%dto%d\n",i*10+waitTime,(i+1)*10+waitTime)rs:=fixedWindowRateLimit("test2",fillInteval,limitNum)fmt.Println("resultis:",rs)time.Sleep(10*time.Second)}}

服务器限制流量(服务器限流怎么办)

根据执行结果可以看到,0-60s总共4个true满足1分钟窗口5个,60-120总共5个true,1个false满足限流,但30-90这1分钟的时间窗总共6个true,超过5个限制。

服务器限制流量(服务器限流怎么办)

1.3方案改进:使用滑动窗口

//segmentNumsplitintevaltimeintosmallersegmentsfuncslidingWindowRatelimit(keystring,fillIntevaltime.Duration,segmentNumint64,limitNumint64)bool{segmentInteval:=fillInteval.Seconds/float64(segmentNum)tick:=float64(time.Now.Unix)/segmentIntevalcurrentKey:=fmt.Sprintf("%s_%d_%d_%d_%f",key,fillInteval,segmentNum,limitNum,tick)

startCount:=0_,err:=client.SetNX(currentKey,startCount,fillInteval).Resultiferr!=nil{panic(err)}quantum,err:=client.Incr(currentKey).Resultiferr!=nil{panic(err)}//addinthenumberoftheprevioustimefortickStart:=segmentInteval;tickStart<fillInteval.Seconds;tickStart+=segmentInteval{tick=tick-1preKey:=fmt.Sprintf("%s_%d_%d_%d_%f",key,fillInteval,segmentNum,limitNum,tick)val,err:=client.Get(preKey).Resultiferr!=nil{val="0"}num,err:=strconv.ParseInt(val,0,64)quantum=quantum+numifquantum>limitNum{client.Decr(currentKey).Resultreturnfalse}}returntrue}

完整代码参见:

https://github.com/skyhackvip/ratelimit/blob/master/slidingwindow.go

滑动窗口增加一个参数segmentNum,表示把固定窗口再分成几段,如上图的0-10...50-60,把1分钟分成6段,代码执行结果如下,30-90,40-100,任意1分钟滑动窗口都满足5个最大限制。

服务器限制流量(服务器限流怎么办)

1.4计数器的适用场景

适用于做API限流,比如对外提供ip定位查询服务api,天气查询api等,可以根据ip做粒度控制,防止恶意刷接口造成异常,也适用于提供API查询服务做配额限制,一般限流后会对请求做丢弃处理。

局限:窗口算法对于流量限制是定速的,对细粒度时间控制突发流量控制能力就有限了。

2.漏斗桶限流

2.1实现原理

漏斗桶形象比喻为一个滤水漏斗,水滴(请求)可能很快把漏斗填满(流量流入),漏斗出来的水滴(流量处理)是匀速固定的,桶满则新进入水滴(请求)会被限流。

服务器限制流量(服务器限流怎么办)

图片来自网络

常用队列方式来实现,请求到达后放入队列中,有一个处理器从队列匀速取出进行处理。当桶满了,新流量过来会被限流。

Uber提供了基于漏斗桶的算法实现可以参考:

https://github.com/uber-go/ratelimit

另外:redis4.0提供了限流模块,redis-cell,该模块使用漏斗算法,并提供原子限流指令。

cl.throttlekeycapacitylimitNumfillInteval

2.2漏斗桶适用场景

漏斗桶更像是对流量进行整形TrafficShaping,所有流量过来都要进行排队,依次出去,可用于做一些论坛博客发帖频率限制。

相对于计数器限流,达到限流后该时间窗口会丢弃一切请求,漏斗在桶满后,由于还会有持续流出,新到达请求还有机会流入。

局限:由于出口处理速率是匀速的,短时有大量突发请求,即使负载压力不大,请求仍需要在队列等待处理。

3.令牌桶限流

3.1实现原理

令牌桶算法是一个桶,匀速向桶里放令牌,控制桶最大容量(令牌最大数)和放入令牌速率(生成令牌/秒)。请求从桶中拿令牌,拿到令牌可以通过,拿不到就被限流了。

当访问量小时,令牌桶可以积累令牌到桶满,而当短时突发流量,积累的令牌能保障大量请求可以立刻拿到令牌,令牌用完了,请求会依赖于新令牌申请速度,这时会退化成类似漏斗桶算法。

具体实现上,可以使用redis的list,启动任务向list匀速放置数据,当有请求时从list取数据,取到代表通过,否则被限流。这么实现是可行的,但有个弊端,就是需要不断操作list,浪费内存空间,而实际上可以使用实时算法计算的方式来计算可用令牌数。

公式:可用令牌数=(当前请求时间-上次请求时间)*令牌生成速率+上次使用后剩余令牌数,当然这个数需要再和桶容量比较求小。

如果可用令牌数>0代表有令牌,剩余令牌数-1,并更新保存本次剩余令牌数和本次请求时间用于下次计算,这种方式也是惰性加载/计算的一种体现。

3.2代码实现

//rateincrementnumberpersecond//capacitytotalnumberinthebucketfuncbucketTokenRateLimit(keystring,fillIntervaltime.Duration,limitNumint64,capacityint64)bool{currentKey:=fmt.Sprintf("%s_%d_%d_%d",key,fillInterval,limitNum,capacity)numKey:="num"lastTimeKey:="lasttime"currentTime:=time.Now.Unix//onlyinitonceclient.HSetNX(currentKey,numKey,capacity).Resultclient.HSetNX(currentKey,lastTimeKey,currentTime).Result//computecurrentavailablenumberresult,_:=client.HMGet(currentKey,numKey,lastTimeKey).ResultlastNum,_:=strconv.ParseInt(result[0].(string),0,64)lastTime,_:=strconv.ParseInt(result[1].(string),0,64)rate:=float64(limitNum)/float64(fillInterval.Seconds)fmt.Println(rate)incrNum:=int64(math.Ceil(float64(currentTime-lastTime)*rate))//incrementnumberfromlasttimetocurrenttimefmt.Println(incrNum)currentNum:=min(lastNum+incrNum,capacity)//canaccessifcurrentNum>0{varfields=map[string]interface{}{lastTimeKey:currentTime,numKey:currentNum-1}a:=client.HMSet(currentKey,fields)fmt.Println(a)returntrue}returnfalse}

还有更多需要可实现细节如预热桶、一次性放入多个令牌、一次性取多个令牌。同时由于原子性问题,通过redis+lua脚本操作(lua实现令牌桶)会更好。

3.3令牌桶适用场景

令牌桶既能够将所有请求平均分布到时间区间内,又能接受突发请求,因此使用最广泛的限流算法,像java中比较有名的guava就有实现。

4.方案对比选择

计数器

漏斗桶

令牌桶

具体实现 使用全局计数

使用队列+处理器

使用漏斗算法

适用场景

API配额/限流

适合限流后丢弃处理

流量整形

适合限流后阻塞排队

大多数场景均可

5.限流部署

5.1“分布式部署”限流单个服务实例

限流代码在应用服务内,使用aop方式(如gin的middleware),当应用请求时(request)进行拦截检查,通过则继续执行请求,否则将被限流进行处理。

funcrateLimitMiddlewaregin.HandlerFunc{returnfunc(c*gin.Context){bucketTokenRateLimit(c.Param("uid"))}}

由于应用服务是分布式集群,每个服务实例中的限流拦截器只能拦截本实例中的请求数,那么对于总体限流就需要有一定策略分摊到每个单体实例中。比如10000次/秒,服务部署10个实例,每个实例限流可以平均分配(1000次/秒),也可根据不同实例不同权重分配。

优点:可以有效防止单机突发流量导致的压垮,满足限流初衷,适合对并发做流量限制。

缺点:由于每个实例的流量不均等,可能有的实例已经限流,有的机器实例仍很空闲,牺牲部分流量。

5.2“集中式部署”使用统一限流服务中心

5.2.1部署统一限流中心

所有服务实例去请求统一限流中心,中心根据流量情况告知服务是否通过,这种方案最大的问题就是多了一次服务调用,同时集中限流器也会成为最大性能瓶颈。

5.2.2限流部署在接入层

一般分布式服务都设有网关层/路由层/接入层,如果集中限流器可部署到其中,可以解决上述多调用问题。一般常用nginx+lua做网关层限流,lua脚本也可以使用上述几种算法。

优点:适合做细粒度限流或访问配额

缺点:对下游单个服务实例或依赖的服务不够平滑,仍有流量突发过载的可能,所以可以结合上面的方式一起部署,多重防护。

5.3服务中心与单机限流结合

可以使用基于请求日志收集,分析日志,根据限流规则做限流服务,分析出限流结果后,下发限流指令(通过队列或集中配中心)到服务节点,节点进行限流控制。

此方案关键在于:日志处理分析的及时性,可采用flink流式计算方式。

5.4限流规则配置

限流关键在于限流规则配置,是针对某个url还是针对一个服务,阈值应该如何设置,时间窗口如何设计,都是需要考虑的因素。

一般分几部分:接口粒度,时间粒度,最大限流数

接口粒度:限流对象可以配置多种限流策略针对服务单个实例,针对整个服务集群,针对某个接口,针对某类接口等。

时间粒度:如上述计数器算法中举例,使用1分钟做限流粒度更容易出某个小粒度时间窗口期出现异常流量。60000次/分钟,1000次/秒,10次/毫秒看似一样,但限流效果不同,时间粒度越细流量整形越好,越平滑,但也不越小越好。对秒杀类场景,瞬时流量非常大,QPS大,适合时间粒度小的。对QPS不大的场景,可以使用大的时间粒度。

最大限流数:一般需要性能压测、业务预期评估、线上监控、往期经验等来做参考设置。

更多考虑,如API接口服务针对vip用户针对普通用户,限流不同,可以用预留、权重、上限等维度进行不同调度,参考dmclock,mclock算法。

5.5限流处理方式

限流后处理方式可以做服务降级(返回默认值、默认页面)、请求丢弃(拒绝请求)、请求排队(阻塞请求)、发送报警人工介入处理等。有直接结合服务降级熔断的如Sentinel、Hystrix。

分享到 :
相关推荐

.live域名怎么样 .live域名可以备案吗(live离线账号注册)

.live域名是新通用顶级域名。有“生活。居住。活力。直播”等含义。在如今互联网直播...

试用云服务器一定要注意这几个方面(试用云服务器一定要注意这几个方面吗)

坚信许多盆友领到使用云服务器全是要想检测网络服务器的特性。因此一般会把网站立即置放在...

服务器软件怎么维护(服务器软件怎么维护运行)

服务器软件维护的方法:1。定期备份数据库中的数据;2。维护服务器的操作系统;3。整理...

RAKsmart服务器怎么样

RAKsmart是一家拥有丰富的行业经验的服务器提供商。其中RAKsmart日本服务...

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注