内容概要：
1、为什么要限流
2、分布式限流解决方案
3、Guava实现令牌限流和漏桶限流
4、SpringBoot结合Redis实现分布式限流
5、SpringCloud GateWay网关限流---微服务SprignCloud 6、Nginx限流
1 为什么要限流
目标
学习在项目开发中为什么要使用限流技术，以及限流的作用。
概述
在分布式领域，我们难免会遇到并发量突增，对后端服务造成高压力，严重甚至会导致系统宕机。为避 免这种问题，我们通常会为接口添加限流、降级、熔断等能力，从而使接口更为健壮。Java领域常见的 开源组件有Netflix的hystrix，阿里系开源的sentinel等，都是蛮不错的限流熔断框架。
图解
拥堵的火车站分流
拥堵的旅游景点，需要用到分流技术
在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和 增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性 能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀 缺资源(秒杀、抢购)、写服务(如评论、下单)、频繁的复杂查询(评论的最后几页)，因此需有一 种手段来限制这些场景的并发/请求量，即限流。
解决一个问题：保护、保证系统一定可用。
2 分布式限流解决方案
扩容
增加物理服务的硬件和设备。
缓存
缓存比较好理解，在大型高并发系统中，如果没有缓存数据库将分分钟被爆，系统也会瞬间瘫痪。使用 缓存不单单能够提升系统访问速度、提高并发访问量，也是保护数据库、保护系统的有效方式。大型网 站一般主要是“读”，缓存的使用很容易被想到。在大型“写”系统中，缓存也常常扮演者非常重要的角
色。比如累积一些数据批量写入，内存里面的缓存队列(生产消费)，以及HBase写数据的机制等等也 都是通过缓存提升系统的吞吐量或者实现系统的保护措施。甚至消息中间件，你也可以认为是一种分布 式的数据缓存。
降级
服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以 此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行 不同的处理。根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。根据服务范围： 可以砍掉某个功能，也可以砍掉某些模块。总之服务降级需要根据不同的业务需求采用不同的降级策 略。主要的目的就是服务虽然有损但是总比没有好。
限流
限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说 系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流 量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。
限流的目的
限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦 达到限制速率则可以拒绝服务(定向到错误页或告知资源没有了)、排队或等待(比如秒杀、评论、下 单)、降级(返回兜底数据或默认数据，如商品详情页库存默认有货)。
一般开发高并发系统常见的限流有：限制总并发数(比如数据库连接池、线程池)、限制瞬时并发数
(如nginx的limit_conn模块，用来限制瞬时并发连接数)、限制时间窗口内的平均速率(如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率)；其他还有如限制远程接口调用速率、限 制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。
先有缓存这个银弹，后有限流来应对618、双十一高并发流量，在处理高并发问题上可以说是如虎添 翼，不用担心瞬间流量导致系统挂掉或雪崩，最终做到有损服务而不是不服务；限流需要评估好，不可 乱用，否则会正常流量出现一些奇怪的问题而导致用户抱怨。
保护、保证系统和网站的正常运行。
使用场景
秒杀、抢购，年底查询密集，评论查询。
3 SpringBoot结合Redis实现分布式限流演进
目标
为什么使用分布式限流解决方案，整个过程是如何来的。
步骤
1：搭建springboot框架
2：导入web依赖，和guava依赖，以及redis依赖
<dependency><groupId>org.springframework.bootgroupId><artifactId>spring-boot-starter-data-redisartifactId>dependency><dependency><groupId>org.springframework.bootgroupId><artifactId>spring-boot-starter-webartifactId>dependency><dependency><groupId>org.springframework.bootgroupId><artifactId>spring-boot-starter-testartifactId><scope>testscope>dependency>3：最简单的限流讲解---计数器限流
package com.itheima.limiting.web;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RestController;@RestControllerpublic class OrderController {// 抢购，抢购数量，也就限流的阈值static long limit = 10;// 计算器，代表请求的用户数量private long count = 0;@GetMapping("/makeorder")public String makeOrder(){long c = ++count;if(c > limit){return "抢购结束，下次在来! count = " + c;}return "恭喜，抢购成功，count = " + c;}}存在问题：
1：当前count没有标记成为static。需要标记成static吗？答案是不需要，因为 @RestController 标记当前类是单例的, 所以在内存中count只有一份，不会出现所谓的多份问题。而是共用的一个计数器。
2：往往在分布式集群的项目中，项目是部署多多台，是多个 jvm。每个jvm都又自己的计数器，这个时候就会引发高并发带来的线程安全问题。
3：那可以使用volatile 吗？答案是不可以。因为volatile只保证成员变量在线程见的可见性，它不保证线程安全。
4：如果线程不安全可以使用synchronized ，这种是没问题的，可以解决线程安全的问题。但是同时带
@GetMapping("/makeorder")public synchronized String makeOrder(){long c = ++count;if(c > limit){return "抢购结束，下次在来! count = " + c;}return "恭喜，抢购成功，count = " + c;}来的隐患就是：性能低下，这个是必然的，如果使用了synchronized关键字，就是上了锁，代码的执行 就编程了串行，一大推的阻塞，如果这个时候又1w的并发，这个时候处理都会造成大量的阻塞。而且 性能极低。在一般的开发中我们都会认为和代码是不适合的。也满足不了我们高并发的需要。那么进行 优化，如何解决呢？原子类。
5：如果在分布式环境下呢？
可以使用分布式缓存来解决这个问题：
为什么不用Lock和synchronized，在单机环境下，是没有问题，但是往往在开发中，大部分情况下是集 群环境，这个适合每个电脑都是独立JVM环境，你是没有办法去控制别人jvm内存中的东西，所以我们 要计数器进行共享。
为什么选择Redis呢？而不是memcache操作呢？
答案很简单：Redis单线程。(基于linux的io模型来架构的，EPOLL 异步IO BIO NIO EPOLL ) jedis redission
代码如下：
引入依赖：
<dependency><groupId>redis.clientsgroupId><artifactId>jedisartifactId><version>3.1.0version>dependency>定义逻辑：
@GetMapping("makeorder2")public String makeOrder2(String name){// 从jedis上获取自增值try(Jedis jedis = new Jedis("localhost",6379)){long c = jedis.incr(name);if(c > limit){return "抢购结束，下次在来! count = " + c;}return "恭喜，抢购成功，count = " + c;}}测试：启动8080和8081两个端口：访问
http://localhost:8081/makeorder2?name=lisi和 http://localhost:8080/makeorder2?name=lisi 模 拟同一个用户在集群环境下的并发问是否共享计数器。答案很明显是可以的。
限流接口的时间窗请求数--时间窗限流
概述
即一个时间窗口内的请求数，如需限制某个接口/服务每秒/每分钟/每天的请求数/调用量。
如果实现呢？
Guava---单机系统
使用LoadingCache限流
package com.itheima.limiting.web;import com.google.common.cache.CacheBuilder;import com.google.common.cache.CacheLoader;import com.google.common.cache.LoadingCache;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RestController;import redis.clients.jedis.Jedis;import java.util.Calendar;import java.util.concurrent.TimeUnit;import java.util.concurrent.atomic.AtomicLong;@RestControllerpublic class OrderGuavaController {// 抢购，抢购数量，也就限流的阈值static long limit = 5;// 限时间窗请求数，限制5r/sLoadingCache<Long,AtomicLong> loadingCache =CacheBuilder.newBuilder().expireAfterAccess(2, TimeUnit.SECONDS).build(new CacheLoader<Long, AtomicLong>() {@Overridepublic AtomicLong load(Long aLong) throws Exception {return new AtomicLong(0);}});@GetMapping("/makeorder3")public String makeOrder() throws Exception{// 当前秒long currentTime = System.currentTimeMillis()/1000L;//long c = atomicLong.incrementAndGet();long c = loadingCache.get(currentTime).incrementAndGet();if(c > limit){return "抢购结束，下次在来! count = " + c;}return "恭喜，抢购成功，count = " + c;}}模拟代码
package com.itheima.limiting.limiter;import java.util.HashMap;import java.util.Map;import java.util.concurrent.ConcurrentHashMap;import java.util.concurrent.ConcurrentMap;import java.util.concurrent.atomic.AtomicLong;public class MyLimiter {private ConcurrentMapmap = new ConcurrentHashMap<>();private long before;public MyLimiter(long before){super();this.before = before;}public AtomicLong get(long key){if(!this.map.containsKey(key)){synchronized (map){if(!this.map.containsKey(key)){map.put(key,new AtomicLong(0L));// 移除指定秒数的计数器this.removeBeforeKey(key);}}}return this.map.get(key);}private void removeBeforeKey(long ckey){for(Long key : this.map.keySet()){// 把哪些超过时间的key，从map中移除出去。if(key + before < ckey){this.map.remove(key);}}}}复制代码分布式限流--Lua脚本
目标
使用lua脚本完成分布式限流
步骤
package com.itheima.limiting.web;import com.google.common.cache.CacheBuilder;import com.google.common.cache.CacheLoader;import com.google.common.cache.LoadingCache;import com.itheima.limiting.limiter.MyLimiter;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RestController;import redis.clients.jedis.Jedis;import java.util.concurrent.TimeUnit;import java.util.concurrent.atomic.AtomicLong;@RestControllerpublic class OrderRedisController {// 抢购，抢购数量，也就限流的阈值static long limit = 5;public String makeorder6(String name) throws Exception{try (Jedis jedis = new Jedis("localhost",6379)){long c = jedis.incr(name);if(c > limit){return (System.currentTimeMillis()/1000)+"抢购结束，下次在来!count = " + c;}else{if(c==1){// 设置过期时间jedis.expire(name,1);}}return (System.currentTimeMillis()/1000) + "恭喜，抢购成功，count= " + c;}}}Lua脚本
local key = KEYS[1] --限流Key(一秒一个)local limit = tonumber(ARGV[1]) --限流大小local expire = ARGV[2] --过期时间-- 获取当前计数器的值local current = tonumber(redis.call('get',key) or "0")-- 如果超过限制大小if current + 1 > limit thenreturn 0Redis处理类测试用例elsecurrent = tonumber(redis.call('INCRBY',key,"1")) --请求数+1if current == 1 then --如果是第一次访问需要设置过期时间redis.call("expire",key,expire) --设置过期时间endendreturn 1 --返回1代表不限流复制代码Redis处理类
package com.itheima.limiting.limiter;import com.google.common.io.Files;import org.springframework.core.io.ClassPathResource;import redis.clients.jedis.Jedis;import java.nio.charset.Charset;public class JedisLuaLimiter {private String luascript;private String key;private String limit;private String expire;public JedisLuaLimiter(String key,String limit,String expire,StringscriptFile){super();this.key = key;this.limit = limit;this.expire = expire;try{this.luascript = Files.asCharSource(newClassPathResource(scriptFile).getFile(), Charset.defaultCharset()).read();}catch(Exception ex){ex.printStackTrace();}}// 尝试获取public boolean tryAcqure(){Jedis jedis = new Jedis("localhost",6379);return (Long)jedis.eval(this.luascript,1,key,limit,expire) == 1L;}}复制代码测试用例
package com.itheima.limiting;import com.itheima.limiting.web.OrderRedisController;import org.junit.jupiter.api.Test;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.test.context.SpringBootTest;import java.util.concurrent.CountDownLatch;import java.util.concurrent.CyclicBarrier;import java.util.concurrent.TimeUnit;@SpringBootTestclass LimitingApplicationTests {@Autowiredprivate OrderRedisController orderRedisController;@Testvoid contextLoads() throws Exception {// 倒计数锁存器CountDownLatch countDownLatch = new CountDownLatch(50);// 循环屏障CyclicBarrier cyclicBarrier = new CyclicBarrier(50);for (int i = 0; i < 50; i++) {new Thread(()->{try{cyclicBarrier.await();}catch(Exception ex){ex.printStackTrace();}try {System.out.println(Thread.currentThread().getName() +"===" + orderRedisController.makeorder6("aicode111"));}catch (Exception ex){ex.printStackTrace();}countDownLatch.countDown();}).start();}try{countDownLatch.await();}catch(Exception ex){ex.printStackTrace();}TimeUnit.SECONDS.sleep(1);System.out.println(Thread.currentThread().getName() + "===" +orderRedisController.makeorder6("aicode111"));}}复制代码削峰填谷-平滑限流某个接口的请求数
当消费端请求骤增时，可以为其配置排队等待的流控规则，以稳定的速度逐步处理这些请求，起到“削峰填谷”的效果，从而避免流量骤增造成系统负载过高。
背景信息
在实际应用中，收到的请求是没有规律的。例如：某应用的处理请求的能力是每秒 10 个。在某一秒，突然到来了 30 个请求，而接下来两秒，都没有请求到达。在这种情况下，如果直接拒绝 20 个请求，应用在接下来的两秒就会空闲。所以，需要把骤增的请求平均到一段时间内，让系统负载保持在请求处
理水位之内，同时尽可能地处理更多请求。
上图中，红色的部分代表超出消息处理能力的部分。把红色部分的消息平均到之后的空闲时间去处理， 这样既可以保证系统负载处在一个稳定的水位，又可以尽可能地处理更多消息。通过配置流控规则，可 以达到消息匀速处理的效果。
功能原理
AHAS 流控降级的排队等待功能，可以把骤增的大量请求匀速分配，以固定的间隔时间让请求通过，起到“削峰填谷”的效果，从而避免流量骤增造成系统负载过高的情况。堆积的请求将会被排队处理，当请 求的预计排队时间超过最大超时时长时，AHAS 将拒绝这部分超时的请求。
例如：配置匀速模式下请求 QPS 为 5，则每 200 ms 处理一条请求，多余的处理任务将排队；同时设置了超时时间为 5s，则预计排队时长超过5s 的处理任务将被直接拒绝。具体操作步骤，参见新建流控规则。
示意图如下：
问题
突发请求，流量整形，整形为匀速请求处理，(比如 5r/s 时间间隔200毫秒处理一个请求，平滑速率).
解决方案：令牌桶算法
package com.itheima.limiting.web;import com.google.common.util.concurrent.RateLimiter;import com.itheima.limiting.limiter.JedisLuaLimiter;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RestController;@RestControllerpublic class OrderGuavaRateLimitController {// 平滑限流请求RateLimiter rateLimiter = RateLimiter.create(4);//@GetMapping("/makeorder7")public String makeorder7() throws Exception{if(!rateLimiter.tryAcquire()){return (System.currentTimeMillis()/1000)+"抢购结束，下次在来!" ;}return (System.currentTimeMillis()/1000) + "恭喜，抢购成功";}}测试代码
package com.itheima.limiting;import com.itheima.limiting.web.OrderGuavaRateLimitController;import com.itheima.limiting.web.OrderRedisController;import org.junit.jupiter.api.Test;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.test.context.SpringBootTest;import java.util.concurrent.CountDownLatch;import java.util.concurrent.CyclicBarrier;import java.util.concurrent.TimeUnit;@SpringBootTestclass LimitingApplicationTests {@Autowiredprivate OrderRedisController orderRedisController;@Autowiredprivate OrderGuavaRateLimitControllerorderGuavaRateLimitController;@Testvoid contextLoads() throws Exception {// 倒计数锁存器CountDownLatch countDownLatch = new CountDownLatch(50);// 循环屏障CyclicBarrier cyclicBarrier = new CyclicBarrier(50);for (int i = 0; i < 50; i++) {new Thread(()->{try{cyclicBarrier.await();}catch(Exception ex){ex.printStackTrace();}try {//System.out.println(Thread.currentThread().getName() + "===" +orderRedisController.makeorder6("aicode111"));System.out.println(Thread.currentThread().getName()+ "===" + orderGuavaRateLimitController.makeorder7());}catch (Exception ex){ex.printStackTrace();}countDownLatch.countDown();}).start();}try{countDownLatch.await();}catch(Exception ex){ex.printStackTrace();}TimeUnit.SECONDS.sleep(1);// System.out.println(Thread.currentThread().getName() + "===" +orderRedisController.makeorder6("aicode111"));System.out.println(Thread.currentThread().getName() + "===" +orderGuavaRateLimitController.makeorder7());}}自定义令牌桶算法
package com.itheima.limiting.limiter;import java.util.Timer;import java.util.TimerTask;import java.util.concurrent.Semaphore;public class MyRateLimiter implements AutoCloseable{// 定义信号量 并发协同工具private Semaphore semaphore;// 限制数量private int limit;// 定时器private Timer timer;public MyRateLimiter(int limit){super();this.limit = limit;this.semaphore = new Semaphore(limit);this.timer = new Timer();// 放入令牌的时间间隔long period = 1000L/limit;// 通过定时器。定时放入令牌timer.scheduleAtFixedRate(new TimerTask() {@Overridepublic void run() {if(semaphore.availablePermits() < limit){semaphore.release();}}},period,period);}public void acquire() throws InterruptedException{this.semaphore.acquire();}public boolean tryAcquire(){return this.semaphore.tryAcquire();}public int availablePermits(){return this.semaphore.availablePermits();}@Overridepublic void close(){System.out.println("自动来关闭了..............");this.timer.cancel();}}漏桶算法
SpringBoot 结合Aop完成限流策略
原理
首先解释下为何采用Redis作为限流组件的核心。
通俗地讲，假设一个用户(用IP判断)每秒访问某服务接口的次数不能超过10次，那么我们可以在
Redis中创建一个键，并设置键的过期时间为60秒。
当一个用户对此服务接口发起一次访问就把键值加1，在单位时间(此处为1s)内当键值增加到10的时 候，就禁止访问服务接口。PS:在某种场景中添加访问时间间隔还是很有必要的。我们本次不考虑间隔 时间，只关注单位时间内的访问次数。
需求
原理已经讲过了，说下需求。
1. 基于Redis的incr及过期机制开发
2. 调用方便，声明式
3. Spring支持
基于上述需求，我们决定基于注解方式进行核心功能开发，基于Spring-boot-starter作为基础环境，从
而能够很好的适配Spring环境。另外，在本次开发中，我们不通过简单的调用Redis的java类库API实现对Redis的incr操作。原因在于，我们要保证整个限流的操作是原子性的，如果用Java代码去做操作及判断，会有并发问题。
这里我决定采用Lua脚本进行核心逻辑的定义。
为何使用Lua
在正式开发前，我简单介绍下对Redis的操作中，为何推荐使用Lua脚本。
1. 减少网络开销: 不使用 Lua 的代码需要向 Redis 发送多次请求, 而脚本只需一次即可, 减少网络传
输;
2. 原子操作: Redis 将整个脚本作为一个原子执行, 无需担心并发, 也就无需事务;
3. 复用: 脚本会永久保存 Redis 中, 其他客户端可继续使用.
Redis添加了对Lua的支持，能够很好的满足原子性、事务性的支持，让我们免去了很多的异常逻辑处理。对于Lua的语法不是本文的主要内容，感兴趣的可以自行查找资料。
正式开发
到这里，我们正式开始手写限流组件的进程。
1. 工程定义
项目基于maven构建，主要依赖Spring-boot-starter，我们主要在springboot上进行开发，因此自定义的开发包可以直接依赖下面这个坐标，方便进行包管理。版本号自行选择稳定版。
<dependency><groupId>org.springframework.bootgroupId><artifactId>spring-boot-starterartifactId><version>1.4.2.RELEASEversion>dependency>1. Redis整合
由于我们是基于Redis进行的限流操作，因此需要整合Redis的类库，上面已经讲到，我们是基于Springboot进行的开发，因此这里可以直接整合RedisTemplate。
1.1 坐标引入
这里我们引入spring-boot-starter-redis的依赖。
<dependency><groupId>org.springframework.bootgroupId><artifactId>spring-boot-starter-redisartifactId><version>1.4.2.RELEASEversion>dependency>2.2 注入CacheManager及RedisTemplate
新建一个Redis的配置类，命名为RedisCacheConfifig，使用javaconfifig形式注入CacheManager及RedisTemplate。为了操作方便，我们采用了Jackson进行序列化。代码如下 ：
@Configuration@EnableCachingpublic class RedisCacheConfig {private static final Logger LOGGER =LoggerFactory.getLogger(RedisCacheConfig.class);@Beanpublic CacheManager cacheManager(RedisTemplate, ?> redisTemplate){CacheManager cacheManager = newRedisCacheManager(redisTemplate);if (LOGGER.isDebugEnabled()) {LOGGER.debug("Springboot Redis cacheManager 加载完成");}return cacheManager;}@Beanpublic RedisTemplate<String, Object>redisTemplate(RedisConnectionFactory factory) {RedisTemplate<String, Object> template = new RedisTemplate<>();template.setConnectionFactory(factory);//使用Jackson2JsonRedisSerializer来序列化和反序列化redis的value值(默认使用JDK的序列化方式)Jackson2JsonRedisSerializer serializer = newJackson2JsonRedisSerializer(Object.class);ObjectMapper mapper = new ObjectMapper();mapper.setVisibility(PropertyAccessor.ALL,JsonAutoDetect.Visibility.ANY);mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);serializer.setObjectMapper(mapper);template.setValueSerializer(serializer);//使用StringRedisSerializer来序列化和反序列化redis的key值template.setKeySerializer(new StringRedisSerializer());template.afterPropertiesSet();LOGGER.info("Springboot RedisTemplate 加载完成");return template;}}注意 要使用 @Confifiguration 标注此类为一个配置类，当然你可以使用 @Component， 但是不推荐，原因在于 @Component 注解虽然也可以当作配置类，但是并不会为其生成CGLIB代理Class，而使用@Confifiguration，CGLIB会为其生成代理类，进行性能的提升。
2.3 调用方application.propertie需要增加Redis配置
我们的包开发完毕之后，调用方的application.properties需要进行相关配置如下：
#单机模式redisspring.redis.host=127.0.0.1spring.redis.port=6379spring.redis.pool.maxActive=8spring.redis.pool.maxWait=-1spring.redis.pool.maxIdle=8spring.redis.pool.minIdle=0spring.redis.timeout=10000spring.redis.password=如果有密码的话，配置password即可。
这里为单机配置，如果需要支持哨兵集群，则配置如下，Java代码不需要改动，只需要变动配置即可。
注意 两种配置不能共存！
#哨兵集群模式# database namespring.redis.database=0# server password 密码，如果没有设置可不配spring.redis.password=# pool settings ...池配置spring.redis.pool.max-idle=8spring.redis.pool.min-idle=0spring.redis.pool.max-active=8spring.redis.pool.max-wait=-1# name of Redis server 哨兵监听的Redis server的名称spring.redis.sentinel.master=mymaster# comma-separated list of host:port pairs 哨兵的配置列表spring.redis.sentinel.nodes=127.0.0.1:26379,127.0.0.1:26479,127.0.0.1:265793. 定义注解
为了调用方便，我们定义一个名为RateLimiter 的注解，内容如下
/*** @author snowalker* @version 1.0* @date 2018/10/27 1:25* @className RateLimiter* @desc 限流注解*/@Target(ElementType.METHOD)@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface RateLimiter {/*** 限流key* @return*/String key() default "rate:limiter";/*** 单位时间限制通过请求数* @return*/long limit() default 10;/*** 过期时间，单位秒* @return*/long expire() default 1;}该注解明确只用于方法，主要有三个属性。
1. key--表示限流模块名，指定该值用于区分不同应用，不同场景，推荐格式为：应用名:模块名:ip:接口名:方法名
2. limit--表示单位时间允许通过的请求数
3. expire--incr的值的过期时间，业务中表示限流的单位时间。
4. 解析注解定义好注解后，需要开发注解使用的切面，这里我们直接使用aspectj进行切面的开发。先看代码
@Aspect@Componentpublic class RateLimterHandler {private static final Logger LOGGER =LoggerFactory.getLogger(RateLimterHandler.class);@AutowiredRedisTemplate redisTemplate;private DefaultRedisScript getRedisScript;@PostConstructpublic void init() {getRedisScript = new DefaultRedisScript<>();getRedisScript.setResultType(Long.class);getRedisScript.setScriptSource(new ResourceScriptSource(newClassPathResource("rateLimter.lua")));LOGGER.info("RateLimterHandler[分布式限流处理器]脚本加载完成");}这里是注入了RedisTemplate，使用其API进行Lua脚本的调用。
init() 方法在应用启动时会初始化DefaultRedisScript，并加载Lua脚本，方便进行调用。
PS: Lua脚本放置在classpath下，通过ClassPathResource进行加载。
@Pointcut("@annotation(com.snowalker.shield.ratelimiter.core.annotation.RateLimiter)")public void rateLimiter() {}这里我们定义了一个切点，表示只要注解了 @RateLimiter 的方法，均可以触发限流操作。
1 @Around("@annotation(rateLimiter)")这段代码的逻辑为，获取 @RateLimiter 注解配置的属性：key、limit、expire，并通过redisTemplate.execute(RedisScript script, List keys, Object... args) 方法传递给Lua脚本进行限流相关操作，逻辑很清晰。这里我们定义如果脚本返回状态为0则为触发限流，1表示正常请求。5. Lua脚本public Object around(ProceedingJoinPoint proceedingJoinPoint,RateLimiter rateLimiter) throws Throwable {if (LOGGER.isDebugEnabled()) {LOGGER.debug("RateLimterHandler[分布式限流处理器]开始执行限流操作");}Signature signature = proceedingJoinPoint.getSignature();if (!(signature instanceof MethodSignature)) {throw new IllegalArgumentException("the Annotation@RateLimter must used on method!");}/*** 获取注解参数*/// 限流模块keyString limitKey = rateLimiter.key();Preconditions.checkNotNull(limitKey);// 限流阈值long limitTimes = rateLimiter.limit();// 限流超时时间long expireTime = rateLimiter.expire();if (LOGGER.isDebugEnabled()) {LOGGER.debug("RateLimterHandler[分布式限流处理器]参数值为-limitTimes={},limitTimeout={}", limitTimes, expireTime);}/*** 执行Lua脚本*/List keyList = new ArrayList();// 设置key值为注解中的值keyList.add(limitKey);/*** 调用脚本并执行*/Long result = (Long) redisTemplate.execute(getRedisScript,keyList, expireTime, limitTimes);if (result == 0) {String msg = "由于超过单位时间=" + expireTime + "-允许的请求次数=" + limitTimes + "[触发限流]";LOGGER.debug(msg);return "false";}if (LOGGER.isDebugEnabled()) {LOGGER.debug("RateLimterHandler[分布式限流处理器]限流执行结果-result={},请求[正常]响应", result);}return proceedingJoinPoint.proceed();}}这段代码的逻辑为，获取 @RateLimiter 注解配置的属性：key、limit、expire，并通过redisTemplate.execute(RedisScript script, List keys, Object... args) 方法传递给Lua脚本进行限流相关操作，逻辑很清晰。
这里我们定义如果脚本返回状态为0则为触发限流，1表示正常请求。
5. Lua脚本
这里是我们整个限流操作的核心，通过执行一个Lua脚本进行限流的操作。脚本内容如下：
--获取KEYlocal key1 = KEYS[1]local val = redis.call('incr', key1)local ttl = redis.call('ttl', key1)--获取ARGV内的参数并打印local expire = ARGV[1]local times = ARGV[2]redis.log(redis.LOG_DEBUG,tostring(times))redis.log(redis.LOG_DEBUG,tostring(expire))redis.log(redis.LOG_NOTICE, "incr "..key1.." "..val);if val == 1 thenredis.call('expire', key1, tonumber(expire))elseif ttl == -1 thenredis.call('expire', key1, tonumber(expire))endendif val > tonumber(times) thenreturn 0endreturn 1逻辑很通俗，我简单介绍下。
1. 首先脚本获取Java代码中传递而来的要限流的模块的key，不同的模块key值一定不能相同，否则会
覆盖！
2. redis.call('incr', key1)对传入的key做incr操作，如果key首次生成，设置超时时间ARGV[1]；(初
始值为1)
3. ttl是为防止某些key在未设置超时时间并长时间已经存在的情况下做的保护的判断；
4. 每次请求都会做+1操作，当限流的值val大于我们注解的阈值，则返回0表示已经超过请求限制，
触发限流。否则为正常请求。当过期后，又是新的一轮循环，整个过程是一个原子性的操作，能够保证单位时间不会超过我们预设的请求阈值。到这里我们便可以在项目中进行测试。
测试
演示地址：
https://github.com/TaXueWWL/shield-ratelimter/tree/master/shleld-ratelimter-demo
这里我贴一下核心代码，我们定义一个接口，并注解 @RateLimiter(key = "ratedemo:1.0.0", limit= 5, expire = 100) 表示模块ratedemo:sendPayment:1.0.0 在100s内允许通过5个请求，这里的参数设置是为了方便看结果。实际中，我们通常会设置1s内允许通过的次数。
@Controllerpublic class TestController {123我们通过RestClient请求接口，日志返回如下：private static final Logger LOGGER =LoggerFactory.getLogger(TestController.class);@ResponseBody@RequestMapping("ratelimiter")@RateLimiter(key = "ratedemo:1.0.0", limit = 5, expire = 100)public String sendPayment(HttpServletRequest request) throwsException {return "正常请求";}}我们过了RestClient求接口，日志回复如下:
2018-10-28 00:00:00.602 DEBUG 17364 --- [nio-8888-exec-1]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:00.688 DEBUG 17364 --- [nio-8888-exec-1]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]限流执行结果-result=1,请求[正常]响应2018-10-28 00:00:00.860 DEBUG 17364 --- [nio-8888-exec-3]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:01.183 DEBUG 17364 --- [nio-8888-exec-4]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:01.520 DEBUG 17364 --- [nio-8888-exec-3]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]限流执行结果-result=1,请求[正常]响应2018-10-28 00:00:01.521 DEBUG 17364 --- [nio-8888-exec-4]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]限流执行结果-result=1,请求[正常]响应2018-10-28 00:00:01.557 DEBUG 17364 --- [nio-8888-exec-5]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:01.558 DEBUG 17364 --- [nio-8888-exec-5]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]限流执行结果-result=1,请求[正常]响应2018-10-28 00:00:01.774 DEBUG 17364 --- [nio-8888-exec-7]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:02.111 DEBUG 17364 --- [nio-8888-exec-8]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始2018-10-28 00:00:02.169 DEBUG 17364 --- [nio-8888-exec-7]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]限流执行结果-result=1,请求[正常]响应2018-10-28 00:00:02.169 DEBUG 17364 --- [nio-8888-exec-8]c.s.s.r.core.handler.RateLimterHandler :由于超过单位时间=100-允许的请求次数=5[触发限流]根据日志能够看到，正常请求5次后，返回限流触发，说明我们的逻辑生效，对前端而言也是可以看到false标记，表明我们的Lua脚本限流逻辑是正确的，这里具体返回什么标记需要调用方进行明确的定义。总结我们通过Redis的incr及expire功能特性，开发定义了一套基于注解的分布式限流操作，核心逻辑基于Lua保证了原子性。达到了很好的限流的目的，生产上，可以基于该特点进行定制自己的限流组件，当然你可以参考本文的代码，相信你写的一定比我的demo更好！在实际应用时也不要太纠结算法问题，因为一些限流算法实现是一样的只是描述不一样；具体使用哪种限流技术还是要根据实际场景来选择，不要一味去找最佳模式，白猫黑猫能解决问题的就是好猫。因在实际工作中遇到过许多人来问如何进行限流，因此本文会详细介绍各种限流手段。那么接下来我们从限流算法、应用级限流、分布式限流、接入层限流来详细学习下限流技术手段。限流就好比保险丝，根据你制定的标准，达到了就拉闸。5、Hystrix或Gateway网关限流2018-10-28 00:00:02.276 DEBUG 17364 --- [io-8888-exec-10]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:02.276 DEBUG 17364 --- [io-8888-exec-10]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]参数值为-limitTimes=5,limitTimeout=1002018-10-28 00:00:02.278 DEBUG 17364 --- [io-8888-exec-10]c.s.s.r.core.handler.RateLimterHandler :由于超过单位时间=100-允许的请求次数=5[触发限流]2018-10-28 00:00:02.445 DEBUG 17364 --- [nio-8888-exec-2]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:02.445 DEBUG 17364 --- [nio-8888-exec-2]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]参数值为-limitTimes=5,limitTimeout=1002018-10-28 00:00:02.446 DEBUG 17364 --- [nio-8888-exec-2]c.s.s.r.core.handler.RateLimterHandler :由于超过单位时间=100-允许的请求次数=5[触发限流]2018-10-28 00:00:02.628 DEBUG 17364 --- [nio-8888-exec-4]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]开始执行限流操作2018-10-28 00:00:02.628 DEBUG 17364 --- [nio-8888-exec-4]c.s.s.r.core.handler.RateLimterHandler :RateLimterHandler[分布式限流处理器]参数值为-limitTimes=5,limitTimeout=1002018-10-28 00:00:02.629 DEBUG 17364 --- [nio-8888-exec-4]c.s.s.r.core.handler.RateLimterHandler :由于超过单位时间=100-允许的请求次数=5[触发限流]根据日志能够看到，正常请求5次后，返回限流触发，说明我们的逻辑生效，对前端而言也是可以看到false标记，表明我们的Lua脚本限流逻辑是正确的，这里具体返回什么标记需要调用方进行明确的定
义。
总结
我们通过Redis的incr及expire功能特性，开发定义了一套基于注解的分布式限流操作，核心逻辑基于Lua保证了原子性。达到了很好的限流的目的，生产上，可以基于该特点进行定制自己的限流组件，当然你可以参考本文的代码，相信你写的一定比我的demo更好！在实际应用时也不要太纠结算法问题，因为一些限流算法实现是一样的只是描述不一样；具体使用哪种限流技术还是要根据实际场景来选择，不要一味去找最佳模式，白猫黑猫能解决问题的就是好猫。因在实际工作中遇到过许多人来问如何进行限流，因此本文会详细介绍各种限流手段。那么接下来我们从限流算法、应用级限流、分布式限流、接入层限流来详细学习下限流技术手段。限流就好比保险丝，根据你制定的标准，达到了就拉闸。
5 Hystrix或Gateway网关限流
6 Nginx限流
令牌桶算法
算法思想是：
令牌以固定速率产生，并缓存到令牌桶中；
令牌桶放满时，多余的令牌被丢弃；
请求要消耗等比例的令牌才能被处理；
令牌不够时，请求被缓存。
漏桶算法
算法思想是：
水(请求)从上方倒入水桶，从水桶下方流出(被处理)；
来不及流出的水存在水桶中(缓冲)，以固定速率流出；
水桶满后水溢出(丢弃)。
这个算法的核心是：缓存请求、匀速处理、多余的请求直接丢弃。
相比漏桶算法，令牌桶算法不同之处在于它不但有一只“桶”，还有个队列，这个桶是用来存放令牌的，队列才是用来存放请求的。
从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理，漏桶算法能够强
行限制数据的实时传输(处理)速率，对突发流量不做额外处理；而令牌桶算法能够在限制数据的平均
传输速率的同时允许某种程度的突发传输。Nginx按请求速率限速模块使用的是漏桶算法，即能够强行保证请求的实时处理速度不会超过设置的阈
值。
Nginx官方版本限制IP的连接和并发分别有两个模块：
limit_req_zone 用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"。
limit_req_conn 用来限制同一时间连接数，即并发限制。
limit_req_zone 参数配置
Syntax: limit_req zone=name [burst=number] [nodelay];Default: —Context: http, server, locationlimit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;第一个参数：$binary_remote_addr 表示通过remote_addr这个标识来做限制，“binary_”的目的
是缩写内存占用量，是限制同一客户端ip地址。
第二个参数：zone=one:10m表示生成一个大小为10M，名字为one的内存区域，用来存储访问的
频次信息。
第三个参数：rate=1r/s表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，还可以有比如30r/m的。
limit_req zone=one burst=5 nodelay;第一个参数：zone=one 设置使用哪个配置区域来做限制，与上面limit_req_zone 里的name对应。
第二个参数：burst=5，重点说明一下这个配置，burst爆发的意思，这个配置的意思是设置一个大小为5的缓冲区当有大量请求(爆发)过来时，超过了访问频次限制的请求可以先放到这个缓冲区内。
第三个参数：nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回503，如果没有设置，则所有请求会等待排队。
例子：
http {limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;server {location /search/ {limit_req zone=one burst=5 nodelay;}}下面配置可以限制特定UA(比如搜索引擎)的访问：
limit_req_zone $anti_spider zone=one:10m rate=10r/s;limit_req zone=one burst=100 nodelay;if ($http_user_agent ~* "googlebot|bingbot|Feedfetcher-Google") {set $anti_spider $http_user_agent;}其他参数
Syntax: limit_req_log_level info | notice | warn | error;Default:limit_req_log_level error;Context: http, server, location当服务器由于limit被限速或缓存时，配置写入日志。延迟的记录比拒绝的记录低一个级别。例子：limit_req_log_level notice 延迟的的基本是info。
Syntax: limit_req_status code;Default:limit_req_status 503;Context: http, server, location设置拒绝请求的返回值。值只能设置 400 到 599 之间。
ngx_http_limit_conn_module 参数配置
这个模块用来限制单个IP的请求数。并非所有的连接都被计数。只有在服务器处理了请求并且已经读取了整个请求头时，连接才被计数。
Syntax: limit_conn zone number;Default: —Context: http, server, locationlimit_conn_zone $binary_remote_addr zone=addr:10m;server {location /download/ {limit_conn addr 1;}一次只允许每个IP地址一个连接。
limit_conn_zone $binary_remote_addr zone=perip:10m;limit_conn_zone $server_name zone=perserver:10m;server {...limit_conn perip 10;limit_conn perserver 100;}可以配置多个limit_conn指令。例如，以上配置将限制每个客户端IP连接到服务器的数量，同时限制连接到虚拟服务器的总数。
Syntax: limit_conn_zone key zone=name:size;Default: —Context: httplimit_conn_zone $binary_remote_addr zone=addr:10m;在这里，客户端IP地址作为关键。请注意，不是 $ remote_addr ，而是使用 $ binary_remote_addr变量。$ remote_addr 变量的大小可以从7到15个字节不等。存储的状态在32位平台上占用32或64字节的内存，在64位平台上总是占用64字节。对于IPv4地址， $ binary_remote_addr 变量的大小始终为4个字节，对于IPv6地址则为16个字节。存储状态在32位平台上始终占用32或64个字节，在64位平台上占用64个字节。一个兆字节的区域可以保持大约32000个32字节的状态或大约16000个64字节的状态。如果区域存储耗尽，服务器会将错误返回给所有其他请求。
Syntax: limit_conn_log_level info | notice | warn | error;Default:limit_conn_log_level error;Context: http, server, location当服务器限制连接数时，设置所需的日志记录级别。
Syntax: limit_conn_status code;Default:limit_conn_status 503;Context: http, server, location设置拒绝请求的返回值。
实战
实例一 限制访问速率
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;server {location / {limit_req zone=mylimit;}}上述规则限制了每个IP访问的速度为2r/s，并将该规则作用于根目录。如果单个IP在非常短的时间内并发发送多个请求，结果会怎样呢？
我们使用单个IP在10ms内发并发送了6个请求，只有1个成功，剩下的5个都被拒绝。我们设置的速度是2r/s，为什么只有1个成功呢，是不是Nginx限制错了？当然不是，是因为Nginx的限流统计是基于毫秒的，我们设置的速度是2r/s，转换一下就是500ms内单个IP只允许通过1个请求，从501ms开始才允许通过第二个请求。
实例二 burst缓存处理
我们看到，我们短时间内发送了大量请求，Nginx按照毫秒级精度统计，超出限制的请求直接拒绝。这在实际场景中未免过于苛刻，真实网络环境中请求到来不是匀速的，很可能有请求“突发”的情况，也就是“一股子一股子”的。Nginx考虑到了这种情况，可以通过burst关键字开启对突发请求的缓存处理，而不是直接拒绝。
来看我们的配置：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;server {location / {limit_req zone=mylimit burst=4;}}我们加入了burst=4，意思是每个key(此处是每个IP)最多允许4个突发请求的到来。如果单个IP在10ms内发送6个请求，结果会怎样呢？
相比实例一成功数增加了4个，这个我们设置的burst数目是一致的。具体处理流程是：1个请求被立即处理，4个请求被放到burst队列里，另外一个请求被拒绝。
通过burst参数，我们使得Nginx限流具备了缓存处理突发流量的能力。但是请注意：burst的作用是让多余的请求可以先放到队列里，慢慢处理。如果不加nodelay参数，队列里的请求不会立即处理，而是按照rate设置的速度，以毫秒级精确的速度慢慢处理。
实例三 nodelay降低排队时间
实例二中我们看到，通过设置burst参数，我们可以允许Nginx缓存处理一定程度的突发，多余的请求可以先放到队列里，慢慢处理，这起到了平滑流量的作用。但是如果队列设置的比较大，请求排队的时间就会比较长，用户角度看来就是RT变长了，这对用户很不友好。有什么解决办法呢？nodelay参数允许请求在排队的时候就立即被处理，也就是说只要请求能够进入burst队列，就会立即被后台worker处理，请注意，这意味着burst设置了nodelay时，系统瞬间的QPS可能会超过rate设置的阈值。nodelay参数要跟burst一起使用才有作用。
延续实例二的配置，我们加入nodelay选项：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;server {location / {limit_req zone=mylimit burst=4 nodelay;}}单个IP 10ms内并发发送6个请求，结果如下：
跟实例二相比，请求成功率没变化，但是总体耗时变短了。这怎么解释呢？实例二中，有4个请求被放到burst队列当中，工作进程每隔500ms(rate=2r/s)取一个请求进行处理，最后一个请求要排队2s才会被处理；实例三中，请求放入队列跟实例二是一样的，但不同的是，队列中的请求同时具有了被处理的资格，所以实例三中的5个请求可以说是同时开始被处理的，花费时间自然变短了。
但是请注意，虽然设置burst和nodelay能够降低突发请求的处理时间，但是长期来看并不会提高吞吐量的上限，长期吞吐量的上限是由rate决定的，因为nodelay只能保证burst的请求被立即处理，但Nginx会限制队列元素释放的速度，就像是限制了令牌桶中令牌产生的速度。
看到这里你可能会问，加入了nodelay参数之后的限速算法，到底算是哪一个“桶”，是漏桶算法还是令牌桶算法？当然还算是漏桶算法。考虑一种情况，令牌桶算法的token为耗尽时会怎么做呢？由于它有一个请求队列，所以会把接下来的请求缓存下来，缓存多少受限于队列大小。但此时缓存这些请求还有
意义吗？如果server已经过载，缓存队列越来越长，RT越来越高，即使过了很久请求被处理了，对用户来说也没什么价值了。所以当token不够用时，最明智的做法就是直接拒绝用户的请求，这就成了漏桶算法。
示例四 自定义返回值
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;server {location / {limit_req zone=mylimit burst=4 nodelay;limit_req_status 598;}}默认情况下 没有配置 status 返回值的状态：
自定义 status 返回值的状态：
247
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
