一次简单的流量控制实现

场景分析

        某个业务接口需要控制接口访问速度，访问速度包括每秒请求(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，还是回到最开始的讨论，需求实现的前提还是得看业务给的时间是不是够充分，毕竟大部分情况都是业务为主。