一、理论基础
1.1、常见限流算法常用的限流算法
(1)令牌桶
实现原理:
以规定的速率往令牌桶中存入Token,用户请求必须获取到令牌中的Token才可以处理请求,如果没有从令牌桶中获取到令牌则丢失该请求。
例子:令牌桶中最多只能存放20个Token,以规定速率存入Token实现在高并发情况下
优势:控制请求的速率匀速相等的(能控制速率)
(2)漏桶-实现原理:
水(请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,出漏桶算法能强行限制数据的传输速率
(3)滑动窗口算法
略
1.2、常用限流框架
(1)Guava工具包——RateLimiter工具类
RateLimiter是基于“令牌桶算法”来实现限流的
(2)Hystrix——略
(3)有Nginx+Lua——略
1.3、服务雪崩、服务降级、熔断、隔离、限流概念
(1)服务雪崩
服务堆积在同一个线程池中,因为所有的请求都是同一个线程池进行处理。这时候如果在高并发情况下,所有的请求全部访问同一个接口,这时候可能会导致其他服务没有线程进行接受请求,这就是服务雪崩效应效应。
解决雪崩效应:使用服务隔离机制(线程池方式和信号量方式)
(2)服务降级
在高并发情况下,防止用户一直等待,使用服务降级方式(直接返回一个友好的提示给客户端,调用fallBack方法)
(3)服务熔断——@EnableHystrix 开启hystrix
目的为了保护服务,在高并发的情况下,如果请求达到一定极限(可以自己设置阔值)如果流量超出了设置阈值。直接拒绝访问,保护当前服务。配合服务降级使用友好提示。
(4)服务隔离
因为默认情况下,只有一个线程池会维护所有的服务接口,如果大量的请求访问同一个接口,达到tomcat 线程池默认极限,可能会导致其他服务无法访问。
线程池隔离的原理:
相当于每个接口(服务)都有自己独立的线程池,因为每个线程池互不影响,这样的话就可以解决服务雪崩效应。
比如可以设置:
- 秒杀接口线程池名称:http-nio-9800-exec-1
- 查询秒杀结果线程名称:http-nio-9800-exec-2
信号量隔离原理:
使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,当请求进来时先判断计数器的数值,若超过设置的最大线程个数则拒绝该请求。若不超过则通行,这时候计数器+1,请求处理完业务成功返回后,计数器-1。
1.4、线程池隔离原理图
如果只用一个线程池,一个接口(比如秒杀接口)的请求峰值,都大于配置的线程数能处理的极限,导致没有空去处理别的接口的请求(比如是查询秒杀结果),从而导致延迟。这时候就要设置每个接口都有自己独立的线程池
二、代码实现
2.1、网关中,基于谷歌RateLimiter+责任链模式实现限流
注意:整个网关服务已经使用责任链模式架构,请参阅之前写的一篇文章——责任链模式实现网关拦截
(1)引入依赖
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</dependency>
(2)网关服务中的,CurrentLimitHandler服务限流
步骤:
- 用户限流频率设置 每秒中限制1个请求;
- 使用redis限制用户访问频率;
- 执行修改库存操作。
/**
* 服务限流
*/
@Component
@Slf4j
public class CurrentLimitHandler extends BaseHandler implements GatewayHandler {
private RateLimiter rateLimiter = RateLimiter.create(1);
@Autowired
private GenerateToken generateToken;
@Override
public void service(RequestContext ctx, HttpServletRequest req, HttpServletResponse response) {
// 1.用户限流频率设置 每秒中限制1个请求
boolean tryAcquire = rateLimiter.tryAcquire(0, TimeUnit.SECONDS);
if (!tryAcquire) {
resultError(500, ctx, "现在抢购的人数过多,请稍等一下下哦!");
return;
}
// 2.使用redis限制用户访问频率
String seckillId = req.getParameter("seckillId");
String seckillToken = generateToken.getListKeyToken(seckillId + "");
if (StringUtils.isEmpty(seckillToken)) {
// log.info(">>>seckillId:{}, 亲,该秒杀已经售空,请下次再来!", seckillId);
resultError(500, ctx, "亲,该秒杀已经售空,请下次再来!");
return;
}
// 3.责任链模式——执行修改库存操作
nextGatewayHandler.service(ctx, req, response);
}
}
2.2、秒杀接口使用hystrix实现线程隔离
(1)秒杀方法添加@HystrixCommand(fallbackMethod = "spikeFallback")——实现服务隔离和降
服务降级方法:
private BaseResponse<JSONObject> spikeFallback(String phone, Long seckillId) {
return setResultError("服务器忙,请稍后重试!");
}
(2)@HystrixCommand注解原理:
(3)Hystrix相关配置
1、Execution相关的属性的配置:
hystrix.command.default.execution.isolation.strategy 隔离策略,默认是Thread, 可选Thread|Semaphore
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时间,默认1000ms
hystrix.command.default.execution.timeout.enabled 执行是否启用超时,默认启用true
hystrix.command.default.execution.isolation.thread.interruptOnTimeout 发生超时是是否中断,默认true
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大并发请求数,默认10,该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效。如果达到最大并发请求数,请求会被拒绝。理论上选择semaphore size的原则和选择thread size一致,但选用semaphore时每次执行的单元要比较小且执行速度快(ms级别),否则的话应该用thread。
semaphore应该占整个容器(tomcat)的线程池的一小部分。
2、Fallback相关配置
这些参数可以应用于Hystrix的THREAD和SEMAPHORE策略
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果并发数达到该设置值,请求会被拒绝和抛出异常并且fallback不会被调用。默认10
hystrix.command.default.fallback.enabled 当执行失败或者请求被拒绝,是否会尝试调用hystrixCommand.getFallback() 。默认true
3、Circuit Breaker相关的配置
hystrix.command.default.circuitBreaker.enabled 用来跟踪circuit的健康性,如果未达标则让request短路。默认true
hystrix.command.default.circuitBreaker.requestVolumeThreshold 一个rolling window内最小的请求数。如果设为20,那么当一个rolling window的时间内(比如说1个rolling window是10秒)收到19个请求,即使19个请求都失败,也不会触发circuit break。默认20
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 触发短路的时间值,当该值设为5000时,则当触发circuit break后的5000毫秒内都会拒绝request,也就是5000毫秒后才会关闭circuit。默认5000
hystrix.command.default.circuitBreaker.errorThresholdPercentage错误比率阀值,如果错误率>=该值,circuit会被打开,并短路所有请求触发fallback。默认50
hystrix.command.default.circuitBreaker.forceOpen 强制打开熔断器,如果打开这个开关,那么拒绝所有request,默认false
hystrix.command.default.circuitBreaker.forceClosed 强制关闭熔断器 如果这个开关打开,circuit将一直关闭且忽略circuitBreaker.errorThresholdPercentage
4、Metrics相关配置
hystrix.command.default.metrics.rollingStats.timeInMilliseconds 设置统计的时间窗口值的,毫秒值,circuit break 的打开会根据1个rolling window的统计来计算。若rolling window被设为10000毫秒,则rolling window会被分成n个buckets,每个bucket包含success,failure,timeout,rejection的次数的统计信息。默认10000
hystrix.command.default.metrics.rollingStats.numBuckets 设置一个rolling window被划分的数量,若numBuckets=10,rolling window=10000,那么一个bucket的时间即1秒。必须符合rolling window % numberBuckets == 0。默认10
hystrix.command.default.metrics.rollingPercentile.enabled 执行时是否enable指标的计算和跟踪,默认true
hystrix.command.default.metrics.rollingPercentile.timeInMilliseconds 设置rolling percentile window的时间,默认60000
hystrix.command.default.metrics.rollingPercentile.numBuckets 设置rolling percentile window的numberBuckets。逻辑同上。默认6
hystrix.command.default.metrics.rollingPercentile.bucketSize 如果bucket size=100,window=10s,若这10s里有500次执行,只有最后100次执行会被统计到bucket里去。增加该值会增加内存开销以及排序的开销。默认100
hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds 记录health 快照(用来统计成功和错误绿)的间隔,默认500ms
5、Request Context 相关配置
hystrix.command.default.requestCache.enabled 默认true,需要重载getCacheKey(),返回null时不缓存
hystrix.command.default.requestLog.enabled 记录日志到HystrixRequestLog,默认true
6、Collapser Properties 相关配置
hystrix.collapser.default.maxRequestsInBatch 单次批处理的最大请求数,达到该数量触发批处理,默认Integer.MAX_VALUE
hystrix.collapser.default.timerDelayInMilliseconds 触发批处理的延迟,也可以为创建批处理的时间+该值,默认10
hystrix.collapser.default.requestCache.enabled 是否对HystrixCollapser.execute() and HystrixCollapser.queue()的cache,默认true
7、ThreadPool 相关配置
线程数默认值10适用于大部分情况(有时可以设置得更小),如果需要设置得更大,那有个基本得公式可以follow:
requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room
每秒最大支撑的请求数 (99%平均响应时间 + 缓存值)
比如:每秒能处理1000个请求,99%的请求响应时间是60ms,那么公式是:
(0.060+0.012)
hystrix.threadpool.default.coreSize 并发执行的最大线程数,默认10
hystrix.threadpool.default.maxQueueSize BlockingQueue的最大队列数,当设为-1,会使用SynchronousQueue,值为正时使用LinkedBlcokingQueue。该设置只会在初始化时有效,之后不能修改threadpool的queue size,除非reinitialising thread executor。默认-1。
hystrix.threadpool.default.queueSizeRejectionThreshold 即使maxQueueSize没有达到,达到queueSizeRejectionThreshold该值后,请求也会被拒绝。因为maxQueueSize不能被动态修改,这个参数将允许我们动态设置该值。if maxQueueSize == -1,该字段将不起作用
hystrix.threadpool.default.keepAliveTimeMinutes 如果corePoolSize和maxPoolSize设成一样(默认实现)该设置无效。如果通过plugin(https://github.com/Netflix/Hystrix/wiki/Plugins)使用自定义实现,该设置才有用,默认1.
hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds 线程池统计指标的时间,默认10000
hystrix.threadpool.default.metrics.rollingStats.numBuckets 将rolling window划分为n个buckets,默认10
上一篇:token+MQ实现修改库存
若对你有帮助,欢迎关注!!点赞!!评论!!