優(yōu)化背景

此前 Dragonfly 的 P2P 下載采用靜態(tài)限流策略，相關配置項在 dfget.yaml 配置文件中：

# 下載服務選項。
download:  
# 總下載限速。  
totalRateLimit: 1024Mi  
# 單個任務下載限速。  perPeerRateLimit: 512Mi

其中 perPeerRateLimit 為單個任務設置流量上限， totalRateLimit 為單個節(jié)點的所有任務設置流量上限。

靜態(tài)限流策略的理想情況是： perPeerRateLimit 設置為20M ， totalRateLimit 設置為 100M ，且該節(jié)點目前運行了 5 個或更多的 P2P 下載任務，這種情況下可以確保所有任務總帶寬不會超過 100M ，且?guī)挄挥行Ю谩?/p>

這種限流策略的缺點是：若perPeerRateLimit 設置為 20M ， totalRateLimit 設置為 100M ，并且當前該節(jié)點只運行了一個下載任務，那么該任務的最大下載速度為 20M ，和最大帶寬 100M 相比，浪費了 80% 的帶寬。

因此，為了最大限度地利用帶寬，需要使用動態(tài)限流來確保任務數(shù)量少時能能充分利用總帶寬，而任務數(shù)量多時也能公平分配帶寬。最終，我們設計出一套根據(jù)上下文進行動態(tài)限流的算法，其中上下文指各任務在過去一秒內(nèi)使用的帶寬，此外，算法還考慮到了任務數(shù)量、任務剩余大小、任務保底帶寬等因素，性能相比原來的靜態(tài)限流算法有顯著提升。

相關代碼分析

perPeerRateLimit 配置項最終賦值給 peerTaskConductor 的pt.limiter ，由 peerTaskConductor 的 DownloadPiece() 函數(shù)里進行限速，pt.waitLimit() 進行實際限流工作，底層調(diào)用 Go 自帶的限流函數(shù) WaitN() 。

TotalRateLimit 配置項則在創(chuàng)建 Daemon 時被賦值給 pieceManager 的pm.limiter ，在 pieceManager 的 DownloadPiece() 和 processPieceFromSource() 函數(shù)中用到的 pm.limiter ，而這兩個函數(shù)都會由 peerTaskConductor 調(diào)用，也就是說 P2P 下載會先進行總限速，之后再進行每個任務單獨限速。

根據(jù)以上分析，Dragonfly 進行任務限速的邏輯為，每個peer task（peerTaskConductor）會有單獨的限速 perPeerRateLimit ，同時 pieceManager 會有 TotalRateLimit 的總限速，以此達到單任務單獨限流，同時限制所有任務總帶寬的效果。

優(yōu)化方案

為了解決此前靜態(tài)限流算法總帶寬利用率不佳的缺點，需要將其改進為動態(tài)限流算法，即總帶寬限速仍恒定，但每個任務的單獨帶寬限速需要根據(jù)上下文適度、定期調(diào)整，已達到最大化利用總帶寬、同時相對公平分配帶寬的目的。

在經(jīng)過數(shù)個改版后，最終我們確定了根據(jù)上下文進行限流的 sampling traffic shaper 動態(tài)限流算法。具體方案為，每個任務的單任務限流交由 TrafficShaper 組建進行統(tǒng)一管理， TrafficShaper 維護當前正在運行的所有任務，并且定期（每秒）更新這些任務的帶寬。

具體來說，上下文指每個任務在上一秒使用的帶寬、每個任務的剩余大小、任務數(shù)量、任務保底帶寬（不能低于 pieceSize ）等因素， TrafficShaper 會根據(jù)這些上下文公平地、效率最大化地為每個任務分配其下一秒的帶寬（具體分配方案詳見下一小節(jié)），實現(xiàn)動態(tài)限流的效果。

優(yōu)化實現(xiàn)

定義 TrafficShaper 接口如下：

// TrafficShaper allocates bandwidth for running tasks dynamically
type TrafficShaper interface {
   // Start starts the TrafficShaper
   Start()   
   // Stop stops the TrafficShaper
   Stop()   
   // AddTask starts managing the new task
   AddTask(taskID string, ptc *peerTaskConductor)
   // RemoveTask removes completed task
   RemoveTask(taskID string)   
   // Record records task's used bandwidth
   Record(taskID string, n int)
   // GetBandwidth gets the total download bandwidth in the past second
   GetBandwidth() int64
}

該接口有兩種實現(xiàn)，第一種是 samplingTrafficShaper 即基于上下文的 traffic shaper ，第二種是 plainTrafficShaper 只記錄帶寬使用情況，除此之外不做任何動態(tài)限流工作，用于和 samplingTrafficShaper 對比性能提升。

同時，將相關配置項修改為如下內(nèi)容：

# 下載服務選項。
download:  
# 總下載限速。
totalRateLimit: 1024Mi
# 單個任務下載限速。
perPeerRateLimit: 512Mi
# traffic shaper類型，有sampling和plain兩種可選  trafficShaperType: sampling

Traffic shaper 的具體運行邏輯為，由peerTaskManager維護trafficShaper，在創(chuàng)建peerTaskManager時，根據(jù)配置初始化trafficShaper，并且調(diào)用Start()函數(shù)，啟動trafficShaper，具體來說，新建time.NewTicker，跨度為 1 秒，也即每秒trafficShaper都會調(diào)用updateLimit()函數(shù)以動態(tài)更新所有任務的帶寬限流。

updateLimit() 函數(shù)會遍歷所有運行中的任務，得出每個任務上一秒消耗的帶寬以及所有任務消耗的總帶寬，隨后根據(jù)任務上一秒使用的帶寬、任務剩余大小等因素，按比例分配帶寬，具體來說首先根據(jù)上一秒該任務使用帶寬以及該任務剩余大小的最大值確定下一秒該任務帶寬，接著所有任務帶寬根據(jù)總帶寬按比例縮放，得到下一秒的真實帶寬；同時需要確保每個任務的帶寬不低于該任務的 pieceSize ，以免出現(xiàn)持續(xù)饑餓狀態(tài)。

在 peerTaskManager 的 getOrCreatePeerTaskConductor() 函數(shù)中，若新建任務，需要帶寬，那么調(diào)用 AddTask() 更新所有任務的帶寬，即按照已有任務的平均任務分配帶寬，然后再根據(jù)總帶寬上限將所有任務的帶寬等比例進行縮放；根據(jù)平均帶寬分配新任務帶寬的優(yōu)勢為，避免了已經(jīng)有一個任務占滿了所有帶寬，有新任務進來時，帶寬會被壓縮到很小 **的情況；同時，不是平均分配帶寬，而是按需等比例分配，可以確保帶寬需求量大的任務仍然帶寬最多。在 peerTaskManager 的 PeerTaskDone() 函數(shù)中，任務完成，不再占用帶寬，調(diào)用 RemoveTask() 按比例擴大所有任務的帶寬。

最后， peerTaskManager 停止時，調(diào)用 Stop 函數(shù)，停止運行 traffic shaper 。

優(yōu)化結果

測試 traffic shaper 相比原有的靜態(tài)限流策略在單個任務、多個任務并發(fā)、多個任務交錯等多種情況下的性能提升，測試結果如下：

注：若不特殊注明，單任務限流為4KB/s，總限流為10KB/s

可以看到， traffic shaper 在單任務、多任務不相交、單任務低帶寬等情況下相比靜態(tài)限流策略性能提升明顯，為 24%~59% 。在多個任務并發(fā)、多個任務交錯等情況下和靜態(tài)限流策略性能相當。綜上，實驗證明 sampling traffic shaper 能很好地解決任務數(shù)量較少時總帶寬被大量浪費的情況，同時在任務數(shù)量較多以及其他復雜情況時依舊能保證和靜態(tài)限流算法持平的效果。

PR 鏈接（已合并）： github.com/dragonflyos…

以上就是Dragonfly P2P 傳輸協(xié)議優(yōu)化代碼解析的詳細內(nèi)容，更多關于Dragonfly P2P 傳輸協(xié)議的資料請關注腳本之家其它相關文章！

最新評論