軟件體系架構閱讀筆記十三

3. 限流模式

服務的容量和性能是有限的，在第3章中會介紹如何在架構設計過程當中評估服務的最大性能和容量，然而，即便咱們在設計階段考慮到了性能壓力的問題，並從設計和部署上解決了這些問題，可是業務量是隨着時間的推移而增加的，忽然上量對於一個飛速發展的平臺來講是很常見的事情。

針對服務忽然上量，咱們必須有限流機制，限流機制通常會控制訪問的併發量，例如每秒容許處理的併發用戶數及查詢量、請求量等。

有以下幾種主流的方法實現限流。

1）計數器

經過原子變量計算單位時間內的訪問次數，若是超出某個閾值，則拒絕後續的請求，等到下一個單位時間再從新計數。

在計數器的實現方法中一般定義了一個循環數組（見下圖），例如：定義5個元素的環形數組，計數週期爲1s，能夠記錄4s內的訪問量，其中有1個元素爲當前時間點的標誌，一般來講每秒程序都會將前面3s的訪問量打印到日誌，供統計分析。

 

 

咱們將時間的秒數除以數組元素的個數5，而後取模，映射到環形數組裏的數據元素，假如當前時間是1 000 000 002s，那麼對應當前時間的環形數組裏的第3個元素，下標爲2。

此時的數組元素的數據以下圖所示。

 

 

在上圖中，當前時間爲1 000 000 002s，對應的計數器在第3個元素，下標爲2，當前請求是在這個時間週期內的第1個訪問請求，程序首先須要對後一個元素即第4個元素，也就是下標爲3的元素清零；在1 000 000 002s內，任何一個請求若是發現下標爲3的元素不爲0，則都會將原子變量3清零，並記錄清零的時間。

這時程序能夠對第3個元素即下標爲2的元素，進行累加並判斷是否達到閾值，若是達到閾值，則拒絕請求，不然請求經過；同時，打印本次及以前3秒的數據訪問量，打印結果以下。

當前：1次，前1s：302次，前2s：201次，前3s：518次

然而，若是當前秒一直沒有請求量，下一秒的計數器始終不能清零，則下一秒的請求到達後要首先清零再使用，並更新清零時間。

在下一秒的請求到達後，若檢查到當前秒對應的原子變量計數器不爲0，並且最後的清零時間不是上一秒，則先對當前秒的計數器清零，再進行累加操做，這避免發生上一秒無請求的場景，或者上一秒的請求因爲線程調度延遲而沒有清零下一秒的場景，後面這種場景發生的機率較小。

另一種實現計數器的簡單方法是單獨啓動一個線程，每隔必定的時間間隔執行對下一秒的原子變量計數器清零操做，這個時間間隔必須小於計數時間間隔。

2）令牌筒

令牌筒是一個流行的實現限流的技術方案，它經過一個線程在單位時間內生產固定數量的令牌，而後把令牌放入隊列，每次請求調用須要從桶中拿取一個令牌，拿到令牌後纔有資格執行請求調用，不然只能等待拿到令牌再執行，或者直接丟棄。

令牌筒的結構以下圖所示。

 

 

3）信號量

限流相似於生活中的漏洞，不管倒入多少油，下面有漏管的流量是有限的，實際上咱們在應用層使用的信號量也能夠實現限流。 

4. 失效轉移模式

若微服務架構中發生了熔斷和限流，則該如何處理被拒絕的請求呢？解決這個問題的模式叫做失效轉移模式，一般分爲下面幾種。

• 採用快速失敗的策略，直接返回使用方錯誤，讓使用方知道發生了問題並自行決定後續處理。
• 是否有備份服務，若是有備份服務，則迅速切換到備份服務。
• 失敗的服務有多是某臺機器有問題，而不是全部機器有問題，例如OOM問題，在這種狀況下適合使用failover策略，採用重試的方法來解決，可是這種方法要求服務提供者的服務實現了冪等性。

 轉載博客：https://blog.csdn.net/kwame211/article/details/78015601