漏斗限流是最常用的限流方法之一，顾明思义，这个算法的灵感源于漏斗（funnel）的结构。
如下图所示，漏斗的容量是有限的，如果将漏嘴堵住，然后一直往里面灌水，它就会变满，直至再也装不进去。如果将漏嘴放开，水就会往下流，流走一部分之后，就又可以继续往里面灌水。如果漏嘴流水的速率大于灌水的速率，那么漏斗永远都装不满。如果漏嘴流水速率小于灌水的速率，那么一旦漏斗满了，灌水就需要暂停并等待漏斗腾出一部分空间。
所以，漏斗的剩余空间就代表着当前行为可以持续进行的数量，漏嘴的流水速率代表着系统允许该行为的最大速率。下面我们使用代码来描述单机漏斗算法。
Funnel对象的make_space方法是漏斗算法的核心，其在每次灌水前都会被调用以触发漏水，给漏斗腾出空间来。能腾出多少空间取决于过去了多久以及流水的速率。Funnel对象占据的空间大小不再和行为的频率成正比，它的空间占用是一个常量。
问题来了，分布式的漏斗算法该如何实现？能不能使用redis的基础数据结构来搞定？
redis 4.0提供了一个限流redis模块，它叫Redis-Cell。该模块也使用了漏斗算法，并提供了原子的限流指令。有了这模块，限流问题就非常简单了。
该模块只有1条指令cl.throttle，它的参数和返回值都略显复杂，接下来让我们来看看这个指令具体该如何使用。
下图中的这个指令的意思是允许“用户老钱回复行为”的频率为每60s最多30次（漏斗速率），漏斗的初始容量为15，也就是说一开始可以连续回复15个帖子，然后才开始受漏斗速率的影响。我们看到这个指令中漏水速率变成了2个参数，替代了之前的单个浮点数。用两个参数相除的结果来表达漏水速率相对单个浮点数要更加直观一些。
在执行限流指令时，如果被拒接了，就需要丢弃或重试。cl.throttle指令考虑得非常周到，连重试时间都帮你算好了，直接取返回结果数组的第四个值进行sleep即可，如果不想阻塞线程，也可以异步定时任务来重试。
