Nginx限速模塊初探 這篇文章解析得很清晰了见间。
記錄一下幾個關(guān)鍵點：
nginx使用的是漏桶算法
核心的代碼是這一行
excess = lr->excess - ctx->rate * ngx_abs(ms) / 1000 + 1000;
以固定的速率（ctx->rate）處理請求
nginx的限流統(tǒng)計是基于滑動窗口嗎
答案：不是
nginx以固定速率處理請求牍汹，不管是怎樣配置限速，它都是轉(zhuǎn)換為多少毫秒取一個請求來處理。什么意思呢？舉例：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
配置了一秒鐘2個請求檐蚜，那就是每500ms處理一個請求贯城。
也可以以分鐘為單位配置加缘，nginx官網(wǎng)文檔提到鸭叙，如果一秒內(nèi)的請求少于一個，可以以分鐘為單位配置：
The rate is specified in requests per second (r/s). If a rate of less than one request per second is desired, it is specified in request per minute (r/m). For example, half-request per second is 30r/m.
配置了30r/m拣宏，那就是30r/60000ms沈贝，每隔2000ms 處理一個請求。
假如說配置了200r/m勋乾，會出現(xiàn)跨2分鐘統(tǒng)計導致限流不準確的情況嗎宋下？例如:
0s---190r---60s---190r---120s
30s---210r---90s
從固定窗口來看，每一分鐘都是190個請求辑莫，沒有超限学歧；但是從滑動窗口來看，從第30s到90s這一分鐘是210個請求各吨，會導致限流不準確嗎枝笨？
答案是不會。
因為nginx會以每300ms一個請求的速率揭蜒，去處理請求伺帘，那么在30s-90s這一分鐘，一定不會超過200r/m忌锯，所以不會出現(xiàn)30s-90s處理了210個請求這種情況。
分布式限流如何做
通常的做法是redis+lua领炫。基于Redis的限流系統(tǒng)的設計這篇文章的限流算法是基于令牌桶的方式偶垮，而且它采取的是觸發(fā)式的方式往桶里放令牌。關(guān)鍵代碼如下：
local reverse_permits = math.floor(((curr_mill_second - last_mill_second) / 1000) * rate)
local expect_curr_permits = reverse_permits + curr_permits;
local_curr_permits = math.min(expect_curr_permits, max_permits);
計算上一次請求令牌的時間帝洪，與本次的時間差似舵，然后再乘以速率，來決定要加多少令牌葱峡。如果兩次請求的時間比較久砚哗，就相當于一次性補充了多個令牌。最后一行代碼表示不能超過最大令牌數(shù)砰奕。
滑動窗口的近似算法
滑動窗口蛛芥，一般的做法是記錄明細，包括時間军援，然后從當前時間開始仅淑，往前框好時間窗口，再統(tǒng)計胸哥。這種做法涯竟，占用存儲空間比較大。
How we built rate limiting capable of scaling to millions of domains 這篇文章提出了一種近似的算法，思路非常簡單庐船、直觀银酬。按作者的說法，還非常有效：
rate = 42 * ((60-15)/60) + 18
= 42 * 0.75 + 18
= 49.5 requests
它的算法是基于這么一個假設：上一時間窗口（固定時間窗口筐钟，例如10點05分這一分鐘）的訪問量是均勻的揩瞪。所以它是按比例取上一時間窗口的統(tǒng)計值。
