目的就是解决下单操作时流量过大的问题、假设有某个商品商品总数只有一个、而抢他的人有几百万个、那么在秒杀时假设没有限流一秒之内一个服务器突然就受到了百万几的压力、这样服务器很容易就会奔溃挂掉。而削峰限流的目的就是为了防止这种事情的发生保护服务器的安全。

大题实现逻辑如上图

1. 验证码 验证码模块使用的是easy capcha、这个使用起来很简单就是指定一个路径然后再用一个输出流指定号宽度创建一个specCaptcha对象、最后out就可以了。

2.大闸的实现 大闸是通过redis缓存实现的、他是在缓存中存一个键值、键为promotion:gate:活动id，然后数量是商品数量的5倍。这里本来应该通过后台来是实现的但没有写后台只能通过测试代码来实现。 3.令牌的实现 验证码通过之后就会去获取令牌了 令牌的具体实现如下图 获取令牌后就可以继续下一步了。

4.限流到交易的实现

5. 队列的实现 队列是通过自动注入的spring的线程池实现的、当令牌通过后会通过线程池创建一个线程taskExecutor.submit来去创建订单进行交易。

防刷是防止黄牛以一些方式买走秒杀时的商品然后再以高价卖出去。比较传统的方式有

最先进的方式是通过手机终端来限制 限制每个手机只能买一定数量的商品、但有些黄牛也有很多手机，还是防不住。

项目中通过初始化一个rateLimiter创建了1000个大小的令牌的限流器、限流器底层是采用令牌桶和漏桶算法两种算法实现的、本项目使用的是令牌桶算法。

有一个限流器、他会去管理一个叫令牌桶的容器，这个容器容量是有限的、初始化时限流器会给令牌桶加入一定量的令牌，并且初始化完之后会有一个令牌生成器会在间隔固定时间内会生成一些令牌到令牌桶中，当令牌桶满之后会溢出多余的令牌。当用户请求时要先经过限流器获取令牌、当令牌桶中没有令牌时则无法访问、有令牌时会给这个请求一个令牌去访问业务并且令牌桶中的令牌数量会减一。

漏桶算法也有一个桶叫漏桶、这个桶放的是水滴也是有一定容量的。当用户发送请求时就像当于一滴水到限流器中、假设漏桶满了就无法请求、没满就会将这个请求加到漏桶中。漏桶会在一定间隔时间内漏出一定量的水滴也就是处理一定量的请求。

漏桶算法是比较稳的、每次只能处理固定量的请求他的速率是固定的。令牌桶则是可能受到突发情况、突然接收到和令牌桶同样数量的请求、那么服务器就要承受这么大的流量。

所以在实际业务中如果你希望比较平稳的流量访问、就用漏桶。若希望能偶尔承受爆发的流量就使用令牌桶。