具体问题
网站的访问ip中，找出进行频繁连接的ip，并对这些ip的访问频率进行限制。
解决方案
Leak Bucket / Token Bucket
概述
将上述的寻找频繁访问ip的问题提升到一个更高的抽象层次，就是网站的流量控制。Leaky Bucket就是一种可以辅助实现流量控制的算法。
在我看来，Leaky Bucket是一个抽象层次略高的算法。它的作用，是通过一种模型（即桶），建立了一种合理地判断流量是否异常的算法。
至于在判断出异常流量后，要触发怎样的操作——抛弃？放入等待队列暂缓发送？——仍然要交给算法的实现者根据具体需求作出选择。这并不是Leaky Bucket的管辖范畴。
根据wiki上的介绍，Leaky Bucket实际上有两种不同的含义。
1）as a meter（作为计量工具）
2）as a queue（作为调度队列）
其中，第一种含义和Token Bucket是等价的，只是表述的角度不同。更有趣的是，第二种含义其实是第一种的特例。这些对比和区别在后面再谈，先整体看一下Leaky Bucket。
Leaky Bucket整体思想
Leaky Bucket的核心抽象模型就如字面意思：一个会漏水的桶。
恒定的速率往下漏水，而上方 时快时慢地会有水进入桶中。当桶还未满时，上方的水可以加入。一旦水满，上方的水就无法加入了。桶满正是算法中的一个的关键触发条件（即流量异常判断成立的条件）。而此条件下如何处理上方欲留下的水，则有了下面两种常见的方式。
Traffic Shaping和Traffic Policing
在桶满水之后，常见的两种处理方式为：
1）暂时拦截住上方水的向下流动，等待桶中的一部分水漏走后，再放行上方水。
2）溢出的上方水直接抛弃。
将水看作网络通信中数据包的抽象，则
方式1起到的效果称为Traffic Shaping，
方式2起到的效果称为Traffic Policing。
由此可见，Traffic Shaping的核心理念是“等待”，Traffic Policing的核心理念是“丢弃”。它们是两种常见的流速控制方法。
算法所需的参数
现在，再回顾一下上面的图，可以看出算法只需要两个参数：
1）桶漏水的速率
2）桶的大小
核心：
利用桶模型判断何时的流量达到异常了
外延：
1）流量异常时的处理方法：traffic policing v.s. traffic shaping
2）处理的数据包是否定长：定长 v.s. 变长
3）桶的大小是否等同于每个tick放行的水量：as a queue v.s. as a meter
总结
回头再看，其实Leaky Bucket是一个很简单的想法，在处理流量控制上也能有不错的效果。wiki上的资料非常繁复，看了我一个下午。其实更多的是在大家运用这个词时的情景多种多样，而没有很好地叙述出算法的核心和外延。
我这里做学习笔记，其实主要也是为了理清自己在学习Leaky Bucket时的混乱，试图真正搞清楚哪些是核心，哪些是外延。
注意事项
在学习的过程中，我发现网上所有的中文资料在谈及Leaky Bucket（漏桶）和Token Bucket（令牌桶）算法时，都是把漏桶看作wiki解释中的第二种。所以，以上文章里的“漏桶”和本文的“Leaky Bucket”并不等价。
我个人倒是并不反对用漏桶来指代wiki的第二种解释，因为这样就可以明确区分出“漏桶”和“令牌桶”。但是，在这种解释下，我们需要牢记，“漏桶”就只是“令牌桶”的一个特例而已了。
转载于:https://blog.51cto.com/leyew/860302
