大傢好，我是老三，最近公司在搞年終大促，隨著各種營銷活動“組合拳”打出，進站流量時不時會有一個小波峰，一般情況下，當然是流量越多越好，前提是系統能杠地住。大傢都知道，一個分佈式系統，有兩個“棄車保帥”的策略：限流和熔斷，這期，我們就來討論一下分佈式系統的限流。
探探限流
帶著問題走近限流
就像我上面說的，流量多，的確是一件好事，但是如果過載，把系統打掛瞭，那大傢都要吃席瞭。
沒逝吧
所以，在各種大促活動之前，要對系統進行壓測，評估整個系統的峰值QPS，要做一些限流的設置，超過一定閾值，就拒絕處理或者延後處理，避免把系統打掛的情況出現。
限流發生在流量進來之前，超過的流量進行限制。
熔斷是一種應對故障的機制，發生在流量進來之後，如果系統發生故障或者異常，熔斷會自動切斷請求，防止故障進一步擴展，導致服務雪崩。
削峰是對流量的平滑處理，通過緩慢地增加請求的處理速率來避免系統瞬時過載。
削峰大概就是水庫，把流量儲存起來，慢慢流，限流大概就是閘口，拒絕超出的流量。
限流的通用流程
那麼具體限流怎麼實現呢？可以概括為以下幾個步驟：
限流通用流程
- 統計請求流量：記錄請求的數量或速率，可以通過計數器、滑動窗口等方式進行統計。
- 判斷是否超過限制：根據設定的限制條件，判斷當前請求流量是否超過限制。
- 執行限流策略：如果請求流量超過限制，執行限流策略，如拒絕請求、延遲處理、返回錯誤信息等。
- 更新統計信息：根據請求的處理結果，更新統計信息，如增加計數器的值、更新滑動窗口的數據等。
- 重復執行以上步驟：不斷地統計請求流量、判斷是否超過限制、執行限流策略、更新統計信息
需要註意的是，具體的限流算法實現可能會根據不同的場景和需求進行調整和優化，比如使用令牌桶算法、漏桶算法等。
單機限流和分佈式限流
我們註意到，在限流的通用流程裡，需要統計請求量、更新統計量，那麼這個請求量的統計和更新就必須維護在一個存儲裡。
假如隻是一個單機版的環境，那就很好辦瞭，直接儲存到本地。
單機vs集群
但是一般來講，我們的服務都是集群部署的，如何來實現多臺機器之間整體的限流呢？
這時候就可以把我們的統計信息放到Tair或Redis等分佈式的K-V存儲中。
四種限流算法與分佈式實現
接下來，我們開始實現一些常見的限流算法，這裡使用Redis作為分佈式存儲，Redis不用多說瞭吧，最流行的分佈式緩存DB；Redission作為Redis客戶端，Redission單純隻是用來做分佈式鎖，有些”屈才“，其實用來作為Redis的客戶端也非常好用。
五種限流算法分佈式實現
在開始之前，我們先簡單準備一下環境，Redis安裝和項目創建就不多說瞭。
- 添加依賴
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.16.2</version>
</dependency>
