限流算法在分布式領域是一個經常被提起的話題，當系統的處理能力有限時，如何阻止計劃外的請求繼續對系統施壓，這是一個需要重視的問題。

除了控制流量，限流還有一個應用目的是用于控制用戶行為，避免垃圾請求。比如在UGC 社區，用戶的發帖、回復、點贊等行為都要嚴格受控，一般要嚴格限定某行為在規定時間內允許的次數，超過了次數那就是非法行為。對非法行為，業務必須規定適當的懲處策略。

如何使用 Redis 來實現簡單限流策略 ？

首先我們來看一個常見 的簡單的限流策略。系統要限定用戶的某個行為在指定的時間里只能允許發生 N 次，如何使用 Redis 的數據結構來實現這個限流的功能？

我們先定義這個接口，理解了這個接口的定義，讀者就應該能明白我們期望達到的功能。

# 指定用戶 user_id 的某個行為 action_key 在特定的時間內 period 只允許發生一定的次數
max_count
def is_action_allowed(user_id, action_key, period, max_count):
return True
# 調用這個接口 , 一分鐘內只允許最多回復 5 個帖子
can_reply = is_action_allowed("laoqian", "reply", 60, 5)
if can_reply:
do_reply()
else:
raise ActionThresholdOverflow()

解決方案

這個限流需求中存在一個滑動時間窗口，想想 zset 數據結構的 score 值，是不是可以通過 score 來圈出這個時間窗口來。而且我們只需要保留這個時間窗口，窗口之外的數據都可以砍掉。那這個 zset 的 value 填什么比較合適呢？它只需要保證唯一性即可，用 uuid 會比較浪費空間，那就改用毫秒時間戳吧。

如圖所示，用一個 zset 結構記錄用戶的行為歷史，每一個行為都會作為 zset 中的一個key 保存下來。同一個用戶同一種行為用一個 zset 記錄。
為節省內存，我們只需要保留時間窗口內的行為記錄，同時如果用戶是冷用戶，滑動時間窗口內的行為是空記錄，那么這個 zset 就可以從內存中移除，不再占用空間。
通過統計滑動窗口內的行為數量與閾值 max_count 進行比較就可以得出當前的行為是否允許。用代碼表示如下：

public class SimpleRateLimiter {
    private Jedis jedis;
    public SimpleRateLimiter(Jedis jedis) {
        this.jedis = jedis;
    }
    public boolean isActionAllowed(String userId, String actionKey, int period, int maxCount) {
        String key = String.format("hist:%s:%s", userId, actionKey);
        long nowTs = System.currentTimeMillis();
        Pipeline pipe = jedis.pipelined();
        pipe.multi();
        pipe.zadd(key, nowTs, "" + nowTs);
        pipe.zremrangeByScore(key, 0, nowTs - period * 1000);
        Response<Long> count = pipe.zcard(key);
        pipe.expire(key, period + 1);
        pipe.exec();
        pipe.close();
        return count.get() <= maxCount;
    }
    public static void main(String[] args) {
        Jedis jedis = new Jedis();
        SimpleRateLimiter limiter = new SimpleRateLimiter(jedis);
        for(int i=0;i<20;i++) {
          System.out.println(limiter.isActionAllowed("laoqian", "reply", 60, 5));
        }
      }
}

它的整體思路就是：每一個行為到來時，都維護一次時間窗口。將時間窗口外的記錄全部清理掉，只保留窗口內的記錄。