@鄭昀匯總?

創(chuàng)建日期：20120925
關(guān)鍵詞索引： 令牌桶算法，漏桶算法
背景： 防注冊機(jī)、秒殺器或掃號等常見電商流量過濾技術(shù)，一般具有如下要求： 1) 高性能。算法簡單高效，能對HTTP Requests進(jìn)行實(shí)時在線處理。 2) 分類錯誤率低。尤其是盡量保證不誤殺正常顧客訪問。 3) 魯棒性強(qiáng)。由于雙方攻防的對抗性很強(qiáng)，所以算法必須適應(yīng)各種類型的攻擊情形（包括DDoS攻擊）。 課題1： 對網(wǎng)站某一個URL/表單提交/Ajax請求的訪問進(jìn)行實(shí)時檢測，找出過于頻繁請求的ip，對這些ip的訪問頻率進(jìn)行限制。 課題2： 對網(wǎng)站開放平臺訪問，對某一個開放接口的調(diào)用，有頻次約束，即針對單一App Key不得超過每小時150次調(diào)用。 翻譯一下： 鄭昀認(rèn)為，我們希望限制住的是，在用M度量的任何時間周期內(nèi)，某一個動作（action）的發(fā)生次數(shù)N。 英文關(guān)鍵詞： rate limiter rate limiting throttle limiter 要控制的是 Average Rate ： 解決思路： 推薦采用令牌桶算法的簡易實(shí)現(xiàn)。 參考資料： 一） Leaky Bucket，漏桶算法。 ? ? ?圖1.1 漏桶算法示意圖 如圖1所示，桶本身具有一個恒定的速率往下漏水，而上方時快時慢地會有水進(jìn)入桶中。當(dāng)桶還未滿時，上方的水可以加入。一旦水滿，上方的水就無法加入了。桶滿正是算法中的一個的關(guān)鍵觸發(fā)條件（即流量異常判斷成立的條件）。 在桶滿水之后，常見的兩種處理方式為： 1）暫時攔截住上方水的向下流動，等待桶中的一部分水漏走后，再放行上方水。 2）溢出的上方水直接拋棄。 將水看作網(wǎng)絡(luò)通信中數(shù)據(jù)包的抽象，則 方式1起到的效果稱為Traffic Shaping， 方式2起到的效果稱為Traffic Policing（流量策略）。 由此可見，Traffic Shaping 的核心理念是“等待”，Traffic Policing 的核心理念是“丟棄”。它們是兩種常見的流速控制方法。 再回顧一下上面的圖，可以看出算法只需要兩個參數(shù)： 1）桶漏水的速率 2）桶的大小 算法核心： 利用桶模型判斷何時的流量達(dá)到異常了 外延： 1）流量異常時的處理方法：traffic policing v.s. traffic shaping 2）處理的數(shù)據(jù)包是否定長：定長 v.s. 變長 3）桶的大小是否等同于每個tick放行的水量：as a queue v.s. as a meter 二） Token Bucket，令牌桶算法是網(wǎng)絡(luò)流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種算法。 漏桶算法不夠靈活，因此加入令牌機(jī)制。? 基本思想： 令牌桶在?traffic shaping 中的應(yīng)用思想如下圖2.1所示。 圖2.1 CAR和CTS進(jìn)行流量控制示意圖

我們主要關(guān)注約定訪問速率(CAR)模式，即：

a. 按特定的速率向令牌桶投放令牌；

b.根據(jù)預(yù)設(shè)的匹配規(guī)則先對報文進(jìn)行分類，不符合匹配規(guī)則的報文不需要經(jīng)過令牌桶的處理，直接發(fā)送；

c.符合匹配規(guī)則的報文，則需要令牌桶進(jìn)行處理。當(dāng)桶中有足夠的令牌則報文可以被繼續(xù)發(fā)送下去，同時令牌桶中的令牌量按報文的長度做相應(yīng)的減少；

d.當(dāng)令牌桶中的令牌不足時，報文將不能被發(fā)送（即丟棄），只有等到桶中生成了新的令牌，報文才可以發(fā)送。這就可以限制報文的流量只能是小于等于令牌生成的速度，達(dá)到限制流量的目的。

實(shí)現(xiàn)： 在數(shù)據(jù)結(jié)構(gòu)上，沒有必要真的實(shí)現(xiàn)一個令牌桶。 基于時間的流逝生成受控制數(shù)量的令牌即可——以時間的流逝來洗滌舊跡，也就是將兩次發(fā)包或者收包的間隔和令牌數(shù)量聯(lián)系起來。 輔助理解的圖形： 令牌桶和漏桶算法最主要的差別在于：漏桶算法能夠強(qiáng)行限制數(shù)據(jù)的傳輸速率，而令牌桶算法能夠在限制數(shù)據(jù)的平均傳輸速率的同時還允許某種程度的突發(fā)傳輸。 ? 在令牌桶算法中，只要令牌桶中存在令牌，那么就允許突發(fā)地傳輸數(shù)據(jù)直到達(dá)到用戶配置的門限，因此它適合于具有突發(fā)特性的流量。? 三）http://developer.linkedin.com/documents/throttle-limits??這是常見的開放平臺限制請求速率的方式。 LinkedIn 比較好的一點(diǎn)就是把Application throttles和Developer throttles分開了。后者是方便聯(lián)調(diào)測試的。 四）Better Rate Limiting in .NET [Penned Objects] 五）鄭昀推薦閱讀，Leaky Bucket算法和Token Bucket算法學(xué)習(xí)筆記，令牌桶算法的應(yīng)用，QoS令牌桶工作原理，用Netfilter模塊實(shí)現(xiàn)基于令牌桶的每IP地址流量控制 六）Token Bucket 算法的 Python 實(shí)現(xiàn)一：kombu.utils.limits.py 代碼：https://github.com/celery/kombu/blob/master/kombu/utils/limits.py 對此實(shí)現(xiàn)一個較為早期的解釋：http://code.activestate.com/recipes/511490/ 即，每次外界調(diào)用 _get_tokens 方法時，才會查一下需要追加多少token。 class TokenBucket(object): def _get_tokens(self): if self._tokens < self.capacity: now = time.time() delta = self.fill_rate * (now - self.timestamp) self._tokens = min(self.capacity, self._tokens + delta) self.timestamp = now return self._tokens 消耗令牌則是通過 consume 函數(shù)，指明本次消耗多少張令牌： def consume(self, tokens):"""Consume tokens from the bucket. Returns True if there were sufficient tokens otherwise False."""if tokens <= self.tokens:self._tokens -= tokenselse:return Falsereturn True ? 七）Rate Limiting 的 memcache-based django?decorator 實(shí)現(xiàn)：Rate limiting with memcached 代碼實(shí)現(xiàn)：https://github.com/simonw/ratelimitcache/blob/master/ratelimitcache.py ? 八）Preventing login hacks: Rate limiting using memcachedPython 實(shí)現(xiàn)。 它明確提出了防字典攻擊防掃號的目的。 既可限制住ip，也可限制住其他字段如 username 。 ? 八）Token Bucket 算法的node.js實(shí)現(xiàn) jhurliman/node-rate-limiter 給出了一個非常便于理解的 Token 消耗方式： 下面是 150次請求/次 范例，每1次請求消耗1個token： var RateLimiter = require('limiter').RateLimiter; // Allow 150 requests per hour (the Twitter search limit). Also understands // 'second', 'minute', 'day', or a number of milliseconds var limiter = new RateLimiter(150, 'hour');// Throttle requests limiter.removeTokens(1, function(err, remainingRequests) {// err will only be set if we request more than the maximum number of// requests we set in the constructor// remainingRequests tells us how many additional requests could be sent// right this momentcallMyRequestSendingFunction(...); }); 下面是150KB/sec 范例，每1個字節(jié)的傳輸就消耗1個token： var BURST_RATE = 1024 * 1024 * 150; // 150KB/sec burst rate var FILL_RATE = 1024 * 1024 * 50; // 50KB/sec sustained rate var TokenBucket = require('limiter').TokenBucket; // We could also pass a parent token bucket in as the last parameter to // create a hierarchical token bucket var bucket = new TokenBucket(BURST_RATE, FILL_RATE, 'second', null);bucket.removeTokens(myData.byteLength, function() {sendMyData(myData); }); ? 九）StackOverflow 上的相關(guān)討論： Throttling method calls to M requests in N seconds What’s a good rate limiting algorithm? Best way to implement request throttling in ASP.NET MVC?

轉(zhuǎn)載于:https://www.cnblogs.com/zhengyun_ustc/archive/2012/11/17/topic1.html

總結(jié)

以上是生活随笔為你收集整理的电商课题I：集群环境下业务限流的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。