场景分析
某个业务接口需要控制接口访问速度,访问速度包括每秒请求(qps)限制,单个用户/IP访问限制,以及其他类型等,因此在这种情况下,设计一个简单的流量控制实现。从控制来看我们得知道三个参数:服务名、接口名、用户唯一特征参数(ip或uid),有这三个参数我们就能做到基本的流量控制功能,或者说是限流功能
方案分析
前端控制目前的做法有:滑动窗口、令牌桶等 ,后端控制目前的做法有: 信号灯、Redis、sentinel(阿里框架)等,本次主要是针对后端控制做出一个方案分析,
信号灯(Semaphore):
信号灯只能适用于单机服务,如果是分布式服务的话,信号灯并不能控制请求量,因为访问的数量 = 机器数 * 信号量, 当然也可以计算出总的数量除以机器数,做到单个节点数的控制,但是这是理想情况下, Nginx首先得是轮询,二是每个节点的响应时间得一致。因此如果是分布式系统的话,信号灯并不适合做流量控制。
Redis:
相比于信号灯,redis不管是单机服务还是分布式服务,都能很好的做到流量控制。使用Redis的原子操作,不用做额外的加锁操作,减去了锁的开销,缺点就是如果redis不可用的话,控制就失效了。
阿里云Sentinel:
目前较多公司选择的一个流量控制框架,功能不用说,非常强大。但在日常开发当中时间也是一个需要考虑的因素,业务给出的时间大部分不够开发做出最优的选择。sentinel缺点是整合、使用、测试所需的时间较Redis长,无法快速完成,不过如果时间充裕的情况下还是推荐使用sentinel,毕竟撑过来N次双十一,是值得信赖的一个框架。
综合考虑下来,选择使用redis作为流量控制的一个简单实现方案。
技术方案
执行流程
逻辑实现:
判断次数:
这里需要保证判断操作的原子性以及并发情况,redis的incr操作保证原子性以及并发情况,因为redis写操作是单线程的.这里不得不佩服redis的作者设计思想.
方法实现:
可以把这个功能抽象成一个AOP注解,每个方法要调用的时候加上注解就行,简单明了.
代码部分:
/**
* 限流注解
*/
@Documented
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RepeatLimit {
/**
* 设置请求锁定时间,默认为 10s
*
* @return 请求锁定时间
*/
int lockTime() default 10;
/**
* 时间内请求数
*
* @return 请求数
*/
int lockNum() default 100;
/**
* 当前服务名
*
* @return 服务名
*/
String serviceName() default "admin";
}
/**
* Description: 限流注解的切面类
*/
@Slf4j
@Aspect
@Component
public class RepeatLimitAspect {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
@Pointcut("@annotation(repeatLimit)")
public void pointCut(RepeatLimit repeatLimit) {
}
@Around("pointCut(noRepeatSubmit)")
public Object around(ProceedingJoinPoint pjp, RepeatLimit repeatLimit) throws Throwable {
ServletRequestAttributes ra = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
HttpServletRequest request = ra.getRequest();
Assert.notNull(request, "request can not null");
int lockSeconds = repeatLimit.lockTime();
int lockNum = repeatLimit.lockNum();
String serviceName = repeatLimit.serviceName();
Boolean isLimit = limitByRedis(request.getMethod(), lockNum, lockSeconds, serviceName);
if (isLimit) {
throw new RuntimeException("当前服务繁忙,请稍后再试");
}
// 没有超过数量限制,则放行
return pjp.proceed();
}
private Boolean limitByRedis(String method, int lockNum, int lockSeconds, String serviceName) {
//通过lua脚本进行incr & 过期时间限制
String script = "local cur = redis.call('incr',KEYS[1]); local t = redis.call('ttl', KEYS[1]); if t == -1 then redis.call('expire', KEYS[1], ARGV[1]) end; return cur";
DefaultRedisScript<Integer> redisScript = new DefaultRedisScript<Integer>(script, Integer.class);
List<String> keyList = new ArrayList<>();
String key = serviceName + ":" + method;
keyList.add(key);
Integer result = redisTemplate.execute(redisScript, keyList, lockSeconds);
int execute = result == null ? 0 : result;
if (execute < lockNum) {
return false;
}
return true;
}
}
进阶版流程:
在写完这个之后,又思考了一会,如果时间充裕的话,这个限流操作其实可以做一个全局的网关,所有的服务限流的话,只需要在网关进行配置即可, 毕竟AOP 代码里面的redis不是每个服务都需要的,如果有的服务没有redis,又想限流,那么这种方法就不可行,所以如果有个网关进行限流的话就完美的解决了这个问题,然后网关的限流方法升级也不会影响到下游服务的使用,做到真正的服务和限流分离,那么大致的流程应该是这样子的
从流程图可以看出,下游并不需要关心限流是怎么实现的,也不用去处理额外的业务逻辑,限流策略和异常处理也可以通过配置来多样化实现,有点类似阿里的sentinel,还是回到最开始的讨论,需求实现的前提还是得看业务给的时间是不是够充分,毕竟大部分情况都是业务为主。