此文参考：https://my.oschina.net/cicadasmile/blog/4328041，此处仅列举常见流控算法，更核心和更偏工业化使用方案，
建议参考阿里的总结： https://developer.aliyun.com/article/765912 标题：单机和分布式场景下，有哪些流控方案？
一、单机流控
- 简单窗口：在指定时间段内只控制总数，不关注流量整形，无法解决临界突变问题（前N秒无请求，但是最后时刻爆发请求）
- 滑动窗口（阿里Sentinel ）：
- 漏桶：
- 令牌桶：Google Ratelimiter
- 滑动日志：
二、分布式流控
- 接入层入口流控：如nginx/LVS
- TokenServer 流控：
- 存储式流控：
Redis 流控：1）简单窗口实现；2）令牌桶/漏桶实现；3）滑动日志实现
2、漏桶算法
漏桶算法是流量整形或速率限制时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。
漏桶算法基本思路：请求（水流）先进入到容器（漏桶）里，漏桶以一定的速度出水，这里就是指流量流出的策略，当流量流入速度过大容器无法承接就会直接溢出，通过该过程限制数据的传输速率。
通过上述流程，不难发现漏桶算法涉及下面几个要素：
-
容器容量：容器的大小直接决定能承接流量的多少，容器一但接近饱和，要么溢出，要么加快流速；流出速度：流量流出的速度取决于服务的请求处理能力，接口支撑的并发越高，流速就可以越大；时间控制：基于时间记录，判断流量流出速度，控制匀速模式，
注意：需要一个基本的判定策略，漏桶算法在系统能承接当前并发流量时，不需要启用。
3、令牌桶算法
令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。
令牌桶算法虽然根本目的也是控制流量速度，但是当令牌桶内的令牌足够多时，则允许流量阶段性的并发。传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消耗的令牌数量不一样。
核心要素
-
令牌桶：存放按照特定的速率生成的令牌，以此控制流量速度。匹配规则：这里的匹配规则更多是服务于分布式系统，例如服务A是系统的核心交易，当出现并发时，基于令牌桶最匹配规则，只允许交易请求通过，例如：常见双十一期间，各大电商平台提示，为保证核心交易，边缘服务的数据延迟或暂停等。 注意：令牌桶算法和漏桶算法的目的虽然相同，但是实现策略是相反的，不过都存在一个问题，为保证大部分请求流量成功，会牺牲小部分请求。
使用令牌桶方案的业界三方件： Google Ratelimiter