限流的本质
高并发。为了避免机器挂了，所以让一部分流量挂了，而不是让整个机器，所有的流量请求都挂了。
基于时间
基于时间的解决方案，是1s内规定多少个请求的问题。
基于滑动时间
基于时间存在的问题？
基于时间的问题是，时间粒度不好控制，因为有可能是前1s的最后250ms和后1s的前250ms，承担了所有的流量。如果是这样，那么机器还是会挂。因为计算流量的时候，是按各自的1s规定的请求数量来决定的。
现在各自计算的时候，流量是没有超过机器能承担的极限的。但是上述的那500ms已经超过了机器的极限，那么机器就挂了。
怎么解决？
把1s分成4段。然后，每隔一段，即250ms，就往前移动时间。这样，上述的那500ms已经超过了机器的极限，但是和基于时间的区别是，现在计算请求数量的时候，已经知道流量请求超过了，所以现在可以限流。但是基于时间，因为两个1s是分开计算请求次数的，所以代码无法判断超过机器极限，那么就会导致机器挂掉。//这个就是滑动时间和时间的唯一区别。本质是一样的，只是时间会滑动而已。
刚才说了，基于时间，有时间粒度的问题。然后，解决方法是移动每一段的时间。但是，还是和基于时间是有一样的问题的，也是时间粒度的问题。无非是一个是1s，一个是250ms。我也可以举个例子，250ms的后50ms和前50ms，也会存在一样的问题。
怎么解决？
基于token令牌
写token限速
基于token令牌
写token + 读token 都限速
基于漏桶。其实也是基于token令牌，一模一样的。
参考
更多细节 + 示意图，参考本博客其他相关文章。
