這個話題的背景源自於hadoop內部的底層rpc處理過程，但是筆者認為針對所有其它rpc處理場景中也會碰到類似的擁塞問題，所以可以拿出來簡單講講。首先來解釋一下這裡的名詞，這裡的rpc擁塞指的是系統被大量的使用者特定的請求堵住了，導致沒辦法有資源來處理其它使用者的正常請求，這裡我們假設請求是被扔到乙個請求佇列中的。這裡我們姑且不討論發起大量請求的使用者操作行為是否合理，但是在這種情況下，確實使得其它rpc被堵住了。本文，我們就來討論這個在分布式系統中經常會遇到的問題，以及對應的解決思路。
此方案思路**於hadoop-9640中提到的faircallqueue的設計，更加詳細的設計細節可詳見此jira。ok，下面筆者來簡單闡述下擁塞控制的解決思路。
優先順序分級
我們說rpc發生擁塞現象，它實際上是一種資源請求相互影響的結果，而這個相互影響的最根本原因是我們沒有對它們進行更一步的分離，而是冗餘在了一起進行處理。這裡首先要改進的是劃分出優先順序關係，每個優先順序對應乙個佇列，比如q0,q1，q3，然後定義乙個規則，數字越小的，優先順序越高。
佇列優先順序確定
佇列優先順序劃分好之後，很重要的乙個操作就是優先順序的確認，在這裡我們當然不會人工的設定請求的優先順序，一種比較通用的，比較智慧型是演算法是根據請求發生頻率確定優先順序，對於使用者而言，要做的是指定這個規則，具體地來說，比如3個佇列，q1佇列的請求，請求頻率在0~10%之間，q2則是10~50%，剩餘50以上的為q3佇列，轉變為實際數量的話，就是100個請求內，請求了50次以上的歸為q2優先順序佇列，10次以內的為q0佇列。重新再來看之前看到的擁塞現象，導致擁塞現象的大部分請求，就會被分到同樣的佇列了，從而在後續的處理中，可以減少對於其它優先順序佇列的影響了。
其次在這裡，頻率的計數統計還要考慮到時限的問題，因為頻率統計是要針對在一定時間內的，比如a時段的頻率不可能完全與b時段的一樣，也不可能一直被延用。在這裡hadoop-9640提到了一種衰減演算法，前面時段內的計數結果通過衰減因子在下一輪的計算中，佔比逐步衰減，這種做法比完全清零統計要平滑許多。
佇列優先順序權重設定
其實各個請求被分到各個優先順序佇列中後，後面的處理就有很多樣的玩法了。比如說，最簡單的，用輪詢的方式從各個佇列中取出一定的批次請求。在這裡，我們提到一種更加靈活的做法，在輪詢的大背景下，再針對各個佇列設定乙個理論保障比重。比如3個優先順序佇列，q0,q1,q2，配置權重比如9,4,1。意為在一次輪詢處理中，在後面的15個請求內，保證處理掉q0佇列的9次請求，q1的4次請求，以及q2的一次請求。
參考資料
[1]. rpc congestion control with faircallqueue
tcp擁塞控制演算法 WebRTC擁塞控制原理解析
webrtc包含三種擁塞控制演算法，gcc bbr和pcc。其中，bbr一開始是針對tcp的擁塞控制提出來的。它的輸入為ack sack，輸出為擁塞視窗 congestion window 傳送速度 pacing rate bbr是怎樣運用到udp，甚至運用到實時流 傳輸之上的？拜讀一下在webrt...
TCP的擁塞控制
計算機網路中的頻寬 交換結點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就會變壞。這種情況就叫做擁塞。擁塞控制就是防止過多的資料注入網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制是乙個全域性性的過程，和流量控制不同，流量...
TCP的擁塞控制
計算機網路中的頻寬 交換結點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就會變壞。這種情況就叫做擁塞。擁塞控制就是防止過多的資料注入網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制是乙個全域性性的過程，和流量控制不同，流量...