保護(hù)高并發(fā)系統(tǒng)的三大利器：緩存、降級(jí)和限流。那什么是限流呢？用我沒讀過太多書的話來講，限流就是限制流量。我們都知道服務(wù)器的處理能力是有上限的，如果超過了上限繼續(xù)放任請(qǐng)求進(jìn)來的話，可能會(huì)發(fā)生不可控的后果。而通過限流，在請(qǐng)求數(shù)量超出閾值的時(shí)候就排隊(duì)等待甚至拒絕服務(wù)，就可以使系統(tǒng)在扛不住過高并發(fā)的情況下做到有損服務(wù)而不是不服務(wù)。

舉個(gè)例子，如各地都出現(xiàn)口罩緊缺的情況，廣州政府為了緩解市民買不到口罩的狀況，上線了預(yù)約服務(wù)，只有預(yù)約到的市民才能到指定的藥店購買少量口罩。這就是生活中限流的情況，說這個(gè)也是希望大家這段時(shí)間保護(hù)好自己，注意防護(hù) ：）

接下來就跟大家分享下接口限流的常見玩法吧，部分算法用python+redis粗略實(shí)現(xiàn)了一下，關(guān)鍵是圖解??！你品，你細(xì)品~

固定窗口法

固定窗口法是限流算法里面最簡單的，比如我想限制1分鐘以內(nèi)請(qǐng)求為100個(gè)，從現(xiàn)在算起的一分鐘內(nèi)，請(qǐng)求就最多就是100個(gè)，這分鐘過完的那一刻把計(jì)數(shù)器歸零，重新計(jì)算，周而復(fù)始。

偽代碼實(shí)現(xiàn)

def can_pass_fixed_window(user, action, time_zone=60, times=30):
  """
  :param user: 用戶唯一標(biāo)識(shí)
  :param action: 用戶訪問的接口標(biāo)識(shí)(即用戶在客戶端進(jìn)行的動(dòng)作)
  :param time_zone: 接口限制的時(shí)間段
  :param time_zone: 限制的時(shí)間段內(nèi)允許多少請(qǐng)求通過
  """
  key = '{}:{}'.format(user, action)
  # redis_conn 表示redis連接對(duì)象
  count = redis_conn.get(key)
  if not count:
    count = 1
    redis_conn.setex(key, time_zone, count)
  if count < times:
    redis_conn.incr(key)
    return True

  return False

這個(gè)方法雖然簡單，但有個(gè)大問題是無法應(yīng)對(duì)兩個(gè)時(shí)間邊界內(nèi)的突發(fā)流量。如上圖所示，如果在計(jì)數(shù)器清零的前1秒以及清零的后1秒都進(jìn)來了100個(gè)請(qǐng)求，那么在短時(shí)間內(nèi)服務(wù)器就接收到了兩倍的(200個(gè))請(qǐng)求，這樣就有可能壓垮系統(tǒng)。會(huì)導(dǎo)致上面的問題是因?yàn)槲覀兊慕y(tǒng)計(jì)精度還不夠，為了將臨界問題的影響降低，我們可以使用滑動(dòng)窗口法。

滑動(dòng)窗口法

滑動(dòng)窗口法，簡單來說就是隨著時(shí)間的推移，時(shí)間窗口也會(huì)持續(xù)移動(dòng)，有一個(gè)計(jì)數(shù)器不斷維護(hù)著窗口內(nèi)的請(qǐng)求數(shù)量，這樣就可以保證任意時(shí)間段內(nèi)，都不會(huì)超過最大允許的請(qǐng)求數(shù)。例如當(dāng)前時(shí)間窗口是0s~60s，請(qǐng)求數(shù)是40，10s后時(shí)間窗口就變成了10s~70s，請(qǐng)求數(shù)是60。

時(shí)間窗口的滑動(dòng)和計(jì)數(shù)器可以使用redis的有序集合(sorted set)來實(shí)現(xiàn)。score的值用毫秒時(shí)間戳來表示，可以利用當(dāng)前時(shí)間戳-時(shí)間窗口的大小來計(jì)算出窗口的邊界，然后根據(jù)score的值做一個(gè)范圍篩選就可以圈出一個(gè)窗口；value的值僅作為用戶行為的唯一標(biāo)識(shí)，也用毫秒時(shí)間戳就好。最后統(tǒng)計(jì)一下窗口內(nèi)的請(qǐng)求數(shù)再做判斷即可。

偽代碼實(shí)現(xiàn)

def can_pass_slide_window(user, action, time_zone=60, times=30):
  """
  :param user: 用戶唯一標(biāo)識(shí)
  :param action: 用戶訪問的接口標(biāo)識(shí)(即用戶在客戶端進(jìn)行的動(dòng)作)
  :param time_zone: 接口限制的時(shí)間段
  :param time_zone: 限制的時(shí)間段內(nèi)允許多少請(qǐng)求通過
  """
  key = '{}:{}'.format(user, action)
  now_ts = time.time() * 1000
  # value是什么在這里并不重要，只要保證value的唯一性即可，這里使用毫秒時(shí)間戳作為唯一值
  value = now_ts 
  # 時(shí)間窗口左邊界
  old_ts = now_ts - (time_zone * 1000)
  # 記錄行為
  redis_conn.zadd(key, value, now_ts)
  # 刪除時(shí)間窗口之前的數(shù)據(jù)
  redis_conn.zremrangebyscore(key, 0, old_ts)
  # 獲取窗口內(nèi)的行為數(shù)量
  count = redis_conn.zcard(key)
  # 設(shè)置一個(gè)過期時(shí)間免得占空間
  redis_conn.expire(key, time_zone + 1)
  if not count or count < times:
    return True
  return False

雖然滑動(dòng)窗口法避免了時(shí)間界限的問題，但是依然無法很好解決細(xì)時(shí)間粒度上面請(qǐng)求過于集中的問題，就例如限制了1分鐘請(qǐng)求不能超過60次，請(qǐng)求都集中在59s時(shí)發(fā)送過來，這樣滑動(dòng)窗口的效果就大打折扣。 為了使流量更加平滑，我們可以使用更加高級(jí)的令牌桶算法和漏桶算法。

令牌桶法

令牌桶算法的思路不復(fù)雜，它先以固定的速率生成令牌，把令牌放到固定容量的桶里，超過桶容量的令牌則丟棄，每來一個(gè)請(qǐng)求則獲取一次令牌，規(guī)定只有獲得令牌的請(qǐng)求才能放行，沒有獲得令牌的請(qǐng)求則丟棄。

偽代碼實(shí)現(xiàn)

def can_pass_token_bucket(user, action, time_zone=60, times=30):
  """
  :param user: 用戶唯一標(biāo)識(shí)
  :param action: 用戶訪問的接口標(biāo)識(shí)(即用戶在客戶端進(jìn)行的動(dòng)作)
  :param time_zone: 接口限制的時(shí)間段
  :param time_zone: 限制的時(shí)間段內(nèi)允許多少請(qǐng)求通過
  """
  # 請(qǐng)求來了就倒水，倒水速率有限制
  key = '{}:{}'.format(user, action)
  rate = times / time_zone # 令牌生成速度
  capacity = times # 桶容量
  tokens = redis_conn.hget(key, 'tokens') # 看桶中有多少令牌
  last_time = redis_conn.hget(key, 'last_time') # 上次令牌生成時(shí)間
  now = time.time()
  tokens = int(tokens) if tokens else capacity
  last_time = int(last_time) if last_time else now
  delta_tokens = (now - last_time) * rate # 經(jīng)過一段時(shí)間后生成的令牌
  if delta_tokens > 1:
    tokens = tokens + tokens # 增加令牌
    if tokens > tokens:
      tokens = capacity
    last_time = time.time() # 記錄令牌生成時(shí)間
    redis_conn.hset(key, 'last_time', last_time)

  if tokens >= 1:
    tokens -= 1 # 請(qǐng)求進(jìn)來了，令牌就減少1
    redis_conn.hset(key, 'tokens', tokens)
    return True
  return False

令牌桶法限制的是請(qǐng)求的平均流入速率，優(yōu)點(diǎn)是能應(yīng)對(duì)一定程度上的突發(fā)請(qǐng)求，也能在一定程度上保持流量的來源特征，實(shí)現(xiàn)難度不高，適用于大多數(shù)應(yīng)用場景。

漏桶算法

漏桶算法的思路與令牌桶算法有點(diǎn)相反。大家可以將請(qǐng)求想象成是水流，水流可以任意速率流入漏桶中，同時(shí)漏桶以固定的速率將水流出。如果流入速度太大會(huì)導(dǎo)致水滿溢出，溢出的請(qǐng)求被丟棄。

通過上圖可以看出漏桶法的特點(diǎn)是：不限制請(qǐng)求流入的速率，但是限制了請(qǐng)求流出的速率。這樣突發(fā)流量可以被整形成一個(gè)穩(wěn)定的流量，不會(huì)發(fā)生超頻。

關(guān)于漏桶算法的實(shí)現(xiàn)方式有一點(diǎn)值得注意，我在瀏覽相關(guān)內(nèi)容時(shí)發(fā)現(xiàn)網(wǎng)上大多數(shù)對(duì)于漏桶算法的偽代碼實(shí)現(xiàn)，都只是實(shí)現(xiàn)了

根據(jù)維基百科，漏桶算法的實(shí)現(xiàn)理論有兩種，分別是基于 meter 的和基于 queue 的，他們實(shí)現(xiàn)的具體思路不同，我大概介紹一下。

基于meter的漏桶

基于 meter 的實(shí)現(xiàn)相對(duì)來說比較簡單，其實(shí)它就有一個(gè)計(jì)數(shù)器，然后有消息要發(fā)送的時(shí)候，就看計(jì)數(shù)器夠不夠，如果計(jì)數(shù)器沒有滿的話，那么這個(gè)消息就可以被處理，如果計(jì)數(shù)器不足以發(fā)送消息的話，那么這個(gè)消息將會(huì)被丟棄。

那么這個(gè)計(jì)數(shù)器是怎么來的呢，基于 meter 的形式的計(jì)數(shù)器就是發(fā)送的頻率，例如你設(shè)置得頻率是不超過 5條/s ，那么計(jì)數(shù)器就是 5，在一秒內(nèi)你每發(fā)送一條消息就減少一個(gè)，當(dāng)你發(fā)第 6 條的時(shí)候計(jì)時(shí)器就不夠了，那么這條消息就被丟棄了。

這種實(shí)現(xiàn)有點(diǎn)類似最開始介紹的固定窗口法，只不過時(shí)間粒度再小一些，偽代碼就不上了。

基于queue的漏桶

基于 queue 的實(shí)現(xiàn)起來比較復(fù)雜，但是原理卻比較簡單，它也存在一個(gè)計(jì)數(shù)器，這個(gè)計(jì)數(shù)器卻不表示速率限制，而是表示 queue 的大小，這里就是當(dāng)有消息要發(fā)送的時(shí)候看 queue 中是否還有位置，如果有，那么就將消息放進(jìn) queue 中，這個(gè) queue 以 FIFO 的形式提供服務(wù)；如果 queue 沒有位置了，消息將被拋棄。

在消息被放進(jìn) queue 之后，還需要維護(hù)一個(gè)定時(shí)器，這個(gè)定時(shí)器的周期就是我們?cè)O(shè)置的頻率周期，例如我們?cè)O(shè)置得頻率是 5條/s，那么定時(shí)器的周期就是 200ms，定時(shí)器每 200ms 去 queue 里獲取一次消息，如果有消息，那么就發(fā)送出去，如果沒有就輪空。

注意，網(wǎng)上很多關(guān)于漏桶法的偽代碼實(shí)現(xiàn)只實(shí)現(xiàn)了水流入桶的部分，沒有實(shí)現(xiàn)關(guān)鍵的水從桶中漏出的部分。如果只實(shí)現(xiàn)了前半部分，其實(shí)跟令牌桶沒有大的區(qū)別噢😯

如果覺得上面的都太難，不好實(shí)現(xiàn)，那么我墻裂建議你嘗試一下redis-cell這個(gè)模塊！

redis-cell

Redis 4.0 提供了一個(gè)限流 Redis 模塊，它叫 redis-cell。該模塊也使用了漏斗算法，并提供了原子的限流指令。有了這個(gè)模塊，限流問題就非常簡單了。 這個(gè)模塊需要單獨(dú)安裝，安裝教程網(wǎng)上很多，它只有一個(gè)指令：

CL.THROTTLE

CL.THROTTLE user123 15 30 60 1
▲ ▲ ▲ ▲ ▲
| | | | └───── apply 1 operation (default if omitted) 每次請(qǐng)求消耗的水滴
| | └──┴─────── 30 operations / 60 seconds 漏水的速率
| └───────────── 15 max_burst 漏桶的容量
└─────────────────── key “user123” 用戶行為

執(zhí)行以上命令之后，redis會(huì)返回如下信息：

> cl.throttle laoqian:reply 15 30 60
1) (integer) 0 # 0 表示允許，1表示拒絕
2) (integer) 16 # 漏桶容量
3) (integer) 15 # 漏桶剩余空間left_quota
4) (integer) -1 # 如果拒絕了，需要多長時(shí)間后再試(漏桶有空間了，單位秒)
5) (integer) 2 # 多長時(shí)間后，漏桶完全空出來(單位秒)

有了上面的redis模塊，就可以輕松對(duì)付大多數(shù)的限流場景了。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論