原創作品，允許轉載，轉載時請務必以超鏈接形式標明文章 原始出處 、作者信息和本聲明。否則將追究法律責任。http://leyew.blog.51cto.com/5043877/860302
網站的訪問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的第二種解釋，因爲這樣就可以明確區分出“漏桶”和“令牌桶”。但是，在這種解釋下，我們需要牢記，“漏桶”就只是“令牌桶”的一個特例而已了。