過載保護：限流與熔斷

接續上一篇 系統高可靠性

系統有了 resource 的規劃，還是無法保證不會有過載的情況發生。這時候就需要透過限流與熔斷來保護系統。 如果沒有做過載保護，當系統遇到過載時，可能會導致系統崩潰，甚至是整個系統的故障。如果有做過載保護，當系統遇到過載時，可以捨棄部分用戶，確保能為絕大部分用戶提供可使用的服務。

限流

通常有兩種限制維度：

• 限制系統的最大資源使用數:

  舉例來說：如在秒殺系統內，一個商品只能提供500件，當今天有100萬個用戶要搶購，系統是沒有必要放全部100萬用戶進來，只需要放500個即可，後面的人可以直接返回已售完的資訊即可。

• 限制速率(限制系統的QPS)

  速率限流又可以分作兩種：

  • 單機限流:
    設定每個機器的最高QPS，當超過這個QPS時，就會拒絕請求。
  • 中央限流:
    需要一個中央的服務系統，在上面給定一個總和最高QPS，這個中央服務就會自己派發請求到底下的機器。

單機限流的算法

漏桶算法

特點如下：

• 漏桶的容量是固定的， request 流出漏桶的速率是固定的。
• request 流入漏桶的速率是不固定的。
• 如果漏桶空了，則不需要流出。
• 如果 request 流入的數量超出了漏桶的容量，則會被拒絕。

Token 桶算法

特點如下：

• Token 桶的容量是固定的， request 流入Token 桶的速率是固定的。
• 當 Token 桶裡面的 token 滿了，則不再放入 token。
• 當 request 收到後，會先去 Token 桶裡面拿 token，如果拿不到 token，則會被拒絕。

比較

• 漏桶算法是固定的速率流出，不固定的速率流入。
  • 比較適合用在request 會瞬間爆發的情況。
• Token 桶算法是固定的速率流入，不固定的速率流出。
  • 比較適合用在request 會持續爆發的情況。

單機限流的實現

限制 request queue 的長度

以下為，一個多線程request的處理示意圖。

依照上面的圖，會有個問題點： request/response queue 的長度該如何配置呢？
大致上的公式如下：

Request Queue = (Request Timeout $/$ Worker Thread 處理一個 request 的時間) $\times$ Worker Thread 數量