主流的几种限流策略，我都可以通过python+redis实现

保护高并发系统的三大利器：缓存、降级和限流。

那什么是限流呢？用我没读过太多书的话来讲，限流就是限制流量。

我们都知道服务器的处理能力是有上限的，如果超过了上限继续放任请求进来的话，可能会发生不可控的后果。

而通过限流，在请求数量超出阈值的时候就排队等待甚至拒绝服务，就可以使系统在扛不住过高并发的情况下做到有损服务而不是不服务。

举个例子，如各地都出现口罩紧缺的情况，武汉政府为了缓解市民买不到口罩的状况，上线了预约服务，只有预约到的市民才能到指定的药店购买少量口罩。

这就是生活中限流的情况，说这个也是希望大家这段时间保护好自己，注意防护 ：

接下来就跟大家分享下接口限流的常见玩法吧，部分算法用python + redis粗略实现了一下，关键是图解啊！你品，你细品~

固定窗口法

固定窗口法是限流算法里面最简单的，比如我想限制1分钟以内请求为100个，从现在算起的一分钟内，请求就最多就是100个，这分钟过完的那一刻把计数器归零，重新计算，周而复始。
伪代码实现

def can_pass_fixed_window(user, action, time_zone=60, times=30):
    """
    :param user: 用户唯一标识
    :param action: 用户访问的接口标识(即用户在客户端进行的动作)
    :param time_zone: 接口限制的时间段
    :param time_zone: 限制的时间段内允许多少请求通过
    """
    key = '{}:{}'.format(user, action)
    # redis_conn 表示redis连接对象
    count = redis_conn.get(key)
    if not count:
        count = 1
        redis_conn.setex(key, time_zone, count)
    if count < times:
        redis_conn.incr(key)
        return True

    return False

这个方法虽然简单，但有个大问题是无法应对两个时间边界内的突发流量。如上图所示，如果在计数器清零的前1秒以及清零的后1秒都进来了100个请求，那么在短时间内服务器就接收到了两倍的(200个)请求，这样就有可能压垮系统。会导致上面的问题是因为我们的统计精度还不够，为了将临界问题的影响降低，我们可以使用滑动窗口法。

滑动窗口法

滑动窗口法，简单来说就是随着时间的推移，时间窗口也会持续移动，有一个计数器不断维护着窗口内的请求数量，这样就可以保证任意时间段内，都不会超过最大允许的请求数。例如当前时间窗口是0s~60s，请求数是40，10s后时间窗口就变成了10s~70s，请求数是60。

时间窗口的滑动和计数器可以使用redis的有序集合(sorted set)来实现。score的值用毫秒时间戳来表示，可以利用 当前时间戳- 时间窗口的大小 来计算出窗口的边界，然后根据score的值做一个范围筛选就可以圈出一个窗口；value的值仅作为用户行为的唯一标识，也用毫秒时间戳