开启阅读模式

网关两种限流调研

2017-12-06

项目经验

许进

项目经验

阅读次

× 文章目录

1. 背景
2. 常见的限流算法
3. 参考链接

背景

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。
一般的中间件都会有单机限流框架，支持两种限流模式：控制速率和控制并发。限流这种东西，应该是来源于网络里面的「流量整型」，通过控制数据包的传输速率和时机，来实现一些性能、服务质量方面的东西。

常见的限流算法有：令牌桶、漏桶。计数器也可以进行粗暴限流实现。

常见的限流算法

常见的限流算法主要有两种：令牌桶算法和漏桶算法。

漏桶算法：如图packet先进入到漏桶里，漏桶以一定的速度出水（packet），当请求过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。

令牌桶(Token Bucket)

令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，直到到达令牌桶容量，令牌不在增加，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。

令牌桶控制的是一个时间窗口内的通过的数据量，在 API 层面我们常说的 QPS、TPS，正好是一个时间窗口内的请求量或者事务量，只不过时间窗口限定在 1s 罢了。

假如项目使用 Java 语言，我们可以轻松地借助 Guava 的 RateLimiter 来实现基于令牌桶的流控。RateLimiter 令牌桶算法的单桶实现，也许是因为在 Web 应用层面单桶实现就够用了，双桶实现就属于过度设计。

RateLimiter 对简单的令牌桶算法做了一些工程上的优化，具体的实现是 SmoothBursty。需要注意的是，RateLimiter 的另一个实现 SmoothWarmingUp，就不是令牌桶了，而是漏桶算法。也许是出于简单起见，RateLimiter 中的时间窗口能且仅能为 1s，如果想搞其他时间单位的限流，只能另外造轮子。

令牌桶

在 Wikipedia 上，令牌桶算法的基本过程如下:

每秒会有 r 个令牌放入桶中，或者说，每过 1/r 秒桶中增加一个令牌
桶中最多存放 b 个令牌，如果桶满了，新放入的令牌会被丢弃
当一个 n 字节的数据包到达时，消耗 n 个令牌，然后发送该数据包
如果桶中可用令牌小于 n，则该数据包将被缓存或丢弃

令牌桶

我们可以使用 Guava 的 RateLimiter 来实现基于令牌桶的流量控制。RateLimiter 令牌桶算法的单桶实现,RateLimiter 对简单的令牌桶算法做了一些工程上的优化，具体的实现是 SmoothBursty。需要注意的是，RateLimiter 的另一个实现 SmoothWarmingUp，就不是令牌桶了，而是漏桶算法。

SmoothBursty 有一个可以放 N 个时间窗口产生的令牌的桶，系统空闲的时候令牌就一直攒着，最好情况下可以扛 N 倍于限流值的高峰而不影响后续请求,就像三峡大坝一样能扛千年一遇的洪水.

下面写个demo 测试一下：

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import com.google.common.util.concurrent.RateLimiter;
public class FlowLimitUtils {
	
	private static final ConcurrentMap<String, RateLimiter> resourceRateLimiterMap = new ConcurrentHashMap<String, RateLimiter>();
	public static void createFlowLimitMap(String resource, double qps) {
		RateLimiter limiter = resourceRateLimiterMap.get(resource);
		if (limiter == null) {
			limiter =RateLimiter.create(qps); 
            resourceRateLimiterMap.putIfAbsent(resource, limiter);
		}
		limiter.setRate(qps);
	}
	public static boolean enter(String resource) throws Exception {
		RateLimiter limiter = resourceRateLimiterMap.get(resource);
		if (limiter == null) {
			throw new Exception(resource);
		}
		if (!limiter.tryAcquire()) {
            System.out.println(">>>>>>>>>>>>>>>>>被限流了>>>>>>>>");
			return true;
		}
		return false;
	}
	 static class TestWork implements Runnable{
		@Override
		public void run() {
			 try {
				if(!enter("test")){
					 System.out.println("++++++++++++ 没有被限流");
				 }
			} catch (Exception e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
			
		}
	}
	
	 public static void main(String[] args) throws InterruptedException {
		 String source="test";
		 double qps=10;
		 createFlowLimitMap(source, qps);
		 Thread.sleep(1000l);
		 ExecutorService pools=Executors.newFixedThreadPool(40);
		 for(int i=0;i<16;i++){
			 TestWork testWork=new TestWork();
			 pools.execute(testWork);
		 }
		 
	} 
}

基于Guava RateLimiter实现限流

1.在Java项目中pom.xml文件中添加依赖

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>19.0-rc2</version>
</dependency>

2.在需要限流的控制类中创建一个reteLimiter对象，用来控制某个接口的请求并发线程数

漏桶(Leaky bucket)算法

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

如上图所示packet先进入到漏桶里，漏桶以一定的速度出水（packet），当请求过大会直接溢出。

可以看出，漏桶算法可以强制网络传输的速率，但无法处理突发传输，比如接口请求量在某一时刻突然激增到了十多倍，如果应用接口毫无限制的处理请求返回数据包，很有可能造成整个应用的不可用。这个时候我们就需要使用令牌桶算法，来控制这种突发传输。

对于限流来说控制速率，相对来说用的很多，简单的比如线程池；
我们可以通过ThreadPoolExecutor来创建一个线程池：

1	new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, milliseconds,runnableTaskQueue, handler);

创建一个线程池需要输入几个参数：

corePoolSize（线程池的基本大小）：当提交一个任务到线程池时，线程池会创建一个线程来执行任务，即使其他空闲的基本线程能够执行新任务也会创建线程，等到需要执行的任务数大于线程池基本大小时就不再创建。如果调用了线程池的prestartAllCoreThreads方法，线程池会提前创建并启动所有基本线程。
runnableTaskQueue（任务队列）：用于保存等待执行的任务的阻塞队列。可以选择以下几个阻塞队列。
ArrayBlockingQueue：是一个基于数组结构的有界阻塞队列，此队列按 FIFO（先进先出）原则对元素进行排序。
LinkedBlockingQueue：一个基于链表结构的阻塞队列，此队列按FIFO （先进先出）排序元素，吞吐量通常要高于ArrayBlockingQueue。静态工厂方法 Executors.newFixedThreadPool()使用了这个队列。
SynchronousQueue：一个不存储元素的阻塞队列。每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQueue，静态工厂方法Executors.newCachedThreadPool使用了这个队列。
PriorityBlockingQueue：一个具有优先级的无限阻塞队列。
maximumPoolSize（线程池最大大小）：线程池允许创建的最大线程数。如果队列满了，并且已创建的线程数小于最大线程数，则线程池会再创建新的线程执行任务。值得注意的是如果使用了无界的任务队列这个参数就没什么效果。
ThreadFactory：用于设置创建线程的工厂，可以通过线程工厂给每个创建出来的线程设置更有意义的名字。
RejectedExecutionHandler（饱和策略）：当队列和线程池都满了，说明线程池处于饱和状态，那么必须采取一种策略处理提交的新任务。这个策略默认情况下是AbortPolicy，表示无法处理新任务时抛出异常。以下是JDK1.5提供的四种策略。
AbortPolicy：直接抛出异常。
CallerRunsPolicy：只用调用者所在线程来运行任务。
DiscardOldestPolicy：丢弃队列里最近的一个任务，并执行当前任务。
DiscardPolicy：不处理，丢弃掉。
当然也可以根据应用场景需要来实现RejectedExecutionHandler接口自定义策略。如记录日志或持久化不能处理的任务。
keepAliveTime（线程活动保持时间）：线程池的工作线程空闲后，保持存活的时间。所以如果任务很多，并且每个任务执行的时间比较短，可以调大这个时间，提高线程的利用率。
TimeUnit（线程活动保持时间的单位）：可选的单位有天（DAYS），小时（HOURS），分钟（MINUTES），毫秒(MILLISECONDS)，微秒(MICROSECONDS, 千分之一毫秒)和毫微秒(NANOSECONDS, 千分之一微秒)。
通过控制以上几个参数的调优，可以最大程度的限制最大引流速率；

参考链接

http://blog.csdn.net/jiesa/article/details/50412027

如果您觉得文章不错,可以打赏我喝一杯咖啡！