分布式限流策略

以下只是一家之言：

　　分布式限流和单机限流在本质上没有太多区别，只不过依赖的数据结构和数据要放在类似 redis 这种支持分布式存储的存储容器上

　　redis 本身单线程对于办法请求的安全性，和基于内存和CPU的高效性 使得 他成为分布式存储容器的不二之选

1. 单窗口限流

　　即是简单的按时间单位计数，时间单位过完之后计数归零。比如说时间单位是 1 秒钟，并且限制这一秒钟 里的请求次数最多是 100 次，也就是 100 QPS

　　那么在这一秒里，如果请求数超过 100，多出的请求将被抛弃。

　　但是实际上，比如在 3分 58秒， 如果 100 个请求都在 58 秒的 最后的 1 ms 发给服务器，然后在 3 分 59 秒的前 1ms 又要 100 个请求发给 服务器，这些请求都是在允许范围之内的，实际上，58秒前半秒 和 59秒后半秒 这一秒 里就有 200 次请求打向服务器并且被接受， 和预期的100 QPS 限制不同。

2. 粒度减小： 滑动窗口限流（多窗口法），假设将 1 秒 分成 5份，并且每秒最多接受 500 次请求

做法是用一个 N 大小的 数组，实现滑动窗口，每个位置代表 200 ms（1s / 5），每个格子中的元素 代表该 200 ms 中请求的 处理次数

当 count ，也就是总请求数 大于 500， 就限流。图中的指针每 200 ms 移动一次，并且移动到下一位置会把该位置上的数清理掉，并且从 count 上减掉，因为这个位置上的请求数已经是一秒前的数据了。

清空出来的位置重新被使用，用来计请求数。

就算有请求聚集的现象，假如红色深色部分代表 100 次请求，因为是聚集在 200 ms 为单位的两个格子里，所以相当于 400 ms 处理了 200 次请求

3.令牌桶，提供服务方 根据自己的自身清空向桶中投放令牌，服务调用方只有从桶中得到令牌，才能真正调用到服务方，如果得不到，就会返回失败错误。

具体令牌桶 可以用消息队列等支持分布式的中间件实现，或者直接嵌入到服务方代码中，视具体清空而定。

4.漏斗桶。让服务方处理请求的速度从之前的 山脉连连，到平原走马，达到削峰填谷的效果。