亿级流量架构之服务限流思路与方法

为何要限流

平常生活中,有哪些须要限流的地方?

像我旁边有一个国家AAAA景区,平时可能根本没什么人前往,可是一到五一或者春节就人满为患,这时候景区管理人员就会实行一系列的政策来限制进入人流量,
为何要限流呢?假如景区能容纳一万人,如今进去了三万人,势必摩肩接踵,整很差还会有事故发生,这样的结果就是全部人的体验都很差,若是发生了事故景区可能还要关闭,致使对外不可用,这样的后果就是全部人都以为体验糟糕透了。

限流的思想就是,在保证可用的状况下尽量多增长进入的人数,其他的人在外面排队等待,保证里面的一万人能够正常游玩。

回到网络上,一样也是这个道理,例如某某明星公布了恋情,访问从平时的50万增长到了500万,系统最多能够支撑200万访问,那么就要执行限流规则,保证是一个可用的状态,不至于服务器崩溃致使全部请求不可用。

限流思路

对系统服务进行限流，通常有以下几个模式：

熔断

系统在设计之初就把熔断措施考虑进去。当系统出现问题时，若是短期内没法修复，系统要自动作出判断，开启熔断开关，拒绝流量访问，避免大流量对后端的过载请求。

系统也应该可以动态监测后端程序的修复状况，当程序已恢复稳定时，能够关闭熔断开关，恢复正常服务。常见的熔断组件有Hystrix以及阿里的Sentinel，两种互有优缺点，能够根据业务的实际状况进行选择。

服务降级

将系统的全部功能服务进行一个分级，当系统出现问题须要紧急限流时，可将不是那么重要的功能进行降级处理，中止服务，这样能够释放出更多的资源供给核心功能的去用。

例如在电商平台中，若是突发流量激增，可临时将商品评论、积分等非核心功能进行降级，中止这些服务，释放出机器和CPU等资源来保障用户正常下单，而这些降级的功能服务能够等整个系统恢复正常后，再来启动，进行补单/补偿处理。除了功能降级之外，还能够采用不直接操做数据库，而所有读缓存、写缓存的方式做为临时降级方案。

延迟处理

这个模式须要在系统的前端设置一个流量缓冲池，将全部的请求所有缓冲进这个池子，不当即处理。而后后端真正的业务处理程序从这个池子中取出请求依次处理，常见的能够用队列模式来实现。这就至关于用异步的方式去减小了后端的处理压力，可是当流量较大时，后端的处理能力有限，缓冲池里的请求可能处理不及时，会有必定程度延迟。后面具体的漏桶算法以及令牌桶算法就是这个思路。

特权处理

这个模式须要将用户进行分类，经过预设的分类，让系统优先处理须要高保障的用户群体，其它用户群的请求就会延迟处理或者直接不处理。

缓存、降级、限流区别

缓存，是用来增长系统吞吐量，提高访问速度提供高并发。

降级，是在系统某些服务组件不可用的时候、流量暴增、资源耗尽等状况下，暂时屏蔽掉出问题的服务，继续提供降级服务，给用户尽量的友好提示，返回兜底数据，不会影响总体业务流程，待问题解决再从新上线服务

限流，是指在使用缓存和降级无效的场景。好比当达到阈值后限制接口调用频率，访问次数，库存个数等，在出现服务不可用以前，提早把服务降级。只服务好一部分用户。

限流的算法

限流算法不少,常见的有三类,分别是计数器算法、漏桶算法、令牌桶算法,下面逐一讲解。

计数器算法

简单粗暴,好比指定线程池大小，指定数据库链接池大小、nginx链接数等,这都属于计数器算法。

计数器算法是限流算法里最简单也是最容易实现的一种算法。举个例子,好比咱们规定对于A接口，咱们1分钟的访问次数不能超过100个。那么咱们能够这么作：在一开 始的时候，咱们能够设置一个计数器counter，每当一个请求过来的时候，counter就加1，若是counter的值大于100而且该请求与第一个请求的间隔时间还在1分钟以内，那么说明请求数过多,拒绝访问；若是该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter,就是这么简单粗暴。

漏桶算法

漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以必定的速度出水，当水流入速度过大会超过桶可接纳的容量时直接溢出，能够看出漏桶算法能强行限制数据的传输速率。

这样作的好处是:

削峰:有大量流量进入时,会发生溢出,从而限流保护服务可用

缓冲:不至于直接请求到服务器,缓冲压力
消费速度固定 由于计算性能固定

令牌桶算法

令牌桶与漏桶类似,不一样的是令牌桶桶中放了一些令牌,服务请求到达后,要获取令牌以后才会获得服务,举个例子,咱们平时去食堂吃饭,都是在食堂内窗口前排队的,这就比如是漏桶算法,大量的人员汇集在食堂内窗口外,以必定的速度享受服务,若是涌进来的人太多,食堂装不下了,可能就有一部分人站到食堂外了,这就没有享受到食堂的服务,称之为溢出,溢出能够继续请求,也就是继续排队,那么这样有什么问题呢?

若是这时候有特殊状况,好比有些赶时间的志愿者啦、或者高三要高考啦,这种状况就是突发状况,若是也用漏桶算法那也得慢慢排队,这也就没有解决咱们的需求,对于不少应用场景来讲，除了要求可以限制数据的平均传输速率外，还要求容许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。如图所示，令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而若是请求须要被处理，则须要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。

令牌桶好处就是,若是某一瞬间访问量剧增或者有突发状况,能够经过改变桶中令牌数量来改变链接数,就比如那个食堂排队吃饭的问题,若是如今不是直接去窗口排队,而是先来楼外拿饭票而后再去排队,那么有高三的学生时能够将增长饭票数量或者优先将令牌给高三的学生,这样比漏桶算法更加灵活。

并发限流

简单来讲就是设置系统阈值总的QPS个数,这些也挺常见的,就拿Tomcat来讲,不少参数就是出于这个考虑,例如

配置的acceptCount 设置响应链接数, maxConnections设置瞬时最大链接数, maxThreads 设置最大线程数,在各个框架或者组件中,并发限流体如今下面几个方面:

• 限制总并发数（如数据库链接池、线程池）
• 限制瞬时并发数（nginx的limit_conn模块，用来限制瞬时并发链接数）
• 限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）
• 其余的还有限制远程接口调用速率、限制MQ的消费速率。
• 另外还能够根据网络链接数、网络流量、CPU或内存负载等来限流。

有了并发限流，就意味着在处理高并发的时候多了一种保护机制，不用担忧瞬间流量致使系统挂掉或雪崩，最终作到有损服务而不是不服务；可是限流须要评估好，不能乱用，不然一些正常流量出现一些奇怪的问题而致使用户体验不好形成用户流失。

接口限流

接口限流分为两个部分,一是限制一段时间内接口调用次数,参照前面限流算法的计数器算法, 二是设置滑动时间窗口算法。

接口总数

控制一段时间内接口被调用的总数量,能够参考前面的计数器算法,再也不赘述。

接口时间窗口

固定时间窗口算法(也就是前面提到的计数器算法)的问题是统计区间太大，限流不够精确，并且在第二个统计区间 时没有考虑与前一个统计区间的关系与影响（第一个区间后半段 + 第二个区间前半段也是一分钟）。为了解决上面咱们提到的临界问题，咱们试图把每一个统计区间分为更小的统计区间，更精确的统计计数。

在上面的例子中,假设QPS能够接受100次查询/秒, 前一分钟前40秒访问很低,后20秒突增,而且这个持续了一段时间,直到第二分钟的第40秒才开始降下来,根据前面的计数方法,前一秒的QPS为94,后一秒的QPS为92,那么没有超过设定参数,可是!可是在中间区域,QPS达到了142,这明显超过了咱们的容许的服务请求数目,因此固定窗口计数器不太可靠,须要滑动窗口计数器。

计数器算法其实就是固定窗口算法, 只是它没有对时间窗口作进一步地划分，因此只有1格；因而可知，当滑动窗口的格子划分的越多，也就是将秒精确到毫秒或者纳秒, 那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

须要注意的是,消耗的空间就越多。

限流实现

这一部分是限流的具体实现,简单说说,毕竟长篇代码没人愿意看。

guava实现

引入包

<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>28.1-jre</version>
</dependency>

核心代码

LoadingCache<Long, AtomicLong> counter = CacheBuilder.newBuilder().
				expireAfterWrite(2, TimeUnit.SECONDS)
				.build(new CacheLoader<Long, AtomicLong>() {

					@Override
					public AtomicLong load(Long secend) throws Exception {
						// TODO Auto-generated method stub
						return new AtomicLong(0);
					}
				});
		counter.get(1l).incrementAndGet();

令牌桶实现

稳定模式(SmoothBursty:令牌生成速度恒定)

public static void main(String[] args) {
		// RateLimiter.create(2)每秒产生的令牌数
		RateLimiter limiter = RateLimiter.create(2);
        // limiter.acquire() 阻塞的方式获取令牌
		System.out.println(limiter.acquire());;
		try {
			Thread.sleep(2000);
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;
		
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;
	}

```RateLimiter.create(2)`` 容量和突发量，令牌桶算法容许将一段时间内没有消费的令牌暂存到令牌桶中，用来突发消费。

渐进模式(SmoothWarmingUp:令牌生成速度缓慢提高直到维持在一个稳定值)

// 平滑限流，从冷启动速率（满的）到平均消费速率的时间间隔
		RateLimiter limiter = RateLimiter.create(2,1000l,TimeUnit.MILLISECONDS);
		System.out.println(limiter.acquire());;
		try {
			Thread.sleep(2000);
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;
		
		System.out.println(limiter.acquire());;
		System.out.println(limiter.acquire());;

超时

boolean tryAcquire = limiter.tryAcquire(Duration.ofMillis(11));

在timeout时间内是否可以得到令牌，异步执行

分布式系统限流

Nginx + Lua实现

可使用resty.lock保持原子特性，请求之间不会产生锁的重入

https://github.com/openresty/lua-resty-lock

使用lua_shared_dict存储数据

local locks = require "resty.lock"

local function acquire()
    local lock =locks:new("locks")
    local elapsed, err =lock:lock("limit_key") --互斥锁 保证原子特性
    local limit_counter =ngx.shared.limit_counter --计数器

    local key = "ip:" ..os.time()
    local limit = 5 --限流大小
    local current =limit_counter:get(key)

    if current ~= nil and current + 1> limit then --若是超出限流大小
       lock:unlock()
       return 0
    end
    if current == nil then
       limit_counter:set(key, 1, 1) --第一次须要设置过时时间，设置key的值为1，
--过时时间为1秒
    else
        limit_counter:incr(key, 1) --第二次开始加1便可
    end
    lock:unlock()
    return 1
end
ngx.print(acquire())