第 15 期 多路複用資源池元件剖析

文章來自於：https://reading.developerlearning.cn/reading/15-2018-08-23-pool-workshop-in-go/

觀看視訊

2018-08-23 22:00:00 分享會之後的答疑。

---

原始碼地址：pool#workshop

一個網友在分享會之後的個人理解：對是獨佔資源物件的複用，提升了最後的 qps，獨佔式方法 TestChanPool() 函式中使用了從資源池獲取 worker 物件，執行完畢後再放回資源池，如果獲取不到則阻塞等待，因此，100 000 請求，每個請求佔用 10ms，可用 worker 物件 50 個，則最後 100 000*10/50 =20s ,視訊中測試結果也顯示 21s 符合預期。而 TestWorkshop() 函式中使用回撥函式對 worker 進行加鎖，每個執行緒使用的那一刻是 worker 物件是被獨佔的，而後續的 do{sleep(10ms)} 是併發執行的，並且根據每個 worker 同時執行的 do 的任務數，進行負載均衡，所以最後測試效能 QPS 能夠有 20 倍的提升。

workshop 中每個協程只在獲得 worker 的那一刻是互斥的，且不會從池子中移除，通過狀態統計達到資源的負載均衡。在業務上真正使用資源時其實是無鎖狀態，所以能被其他協程同時使用，進而吞吐量提升。業務邏輯耗時越長，相比獨佔式資源池的吞吐量優勢越顯著。本機測試 50 個資源 10ms 時可提升 20 倍。

為什麼不使用輪詢使用資源，程式碼實現會更簡單？

實際場景中每次業務邏輯耗時不相同，輪詢並不能保證真的負載均衡。尤其是當突發異常時，可能導致負載失衡。

為什麼長連線非同步通訊不使用一條連線而是連線池？

說到長連線非同步通訊，為什麼不使用一條連線而是連線池，其實涉及到多條連線搶佔頻寬和 TCP 丟包後速率下降的問題。這對於下載場景（迅雷就是這麼做的）和使用共享雲主機的場景比較有用。 具體可以看這篇文章：為什麼多 TCP 連線比單 TCP 連線傳輸快

以前在做加速的一項就是多執行緒下載，開啟多個 tcp 連線，同時下載，比只有一個連線下載快多了。

workshop 的使用場景

使用 workshop 的前提就是該資源可以被同時使用，比如長連線的非同步 IO 通訊。

對於長連線非同步通訊時，如果使用了獨佔式連線池只會起到反效果，讓它和同步通訊沒差別，還不如不用池子。workshop 就是適用於這個場景的。

長連線：同步和非同步方式。

同步方式下客戶端所有請求共用同一連線，在獲得連線後要對連線加鎖，在讀寫結束後才解鎖釋放連線，效能低下，基本很少採用，唯一優點是實現極其簡單。

非同步方式下所有請求都帶有訊息 ID，因此可以批量傳送請求，非同步接收回復，所有請求和回覆的訊息都共享同一連線，通道得到最大化利用，因此吞吐量最大。

這個時候接收端的處理能力也要求比較高，一般都是獨立的一個（或者多個）收包執行緒（或者程式）防止核心緩衝區被填滿影響網路吞吐量。缺點是實現複雜，需要非同步狀態機，需要增加負載均衡和連線健康度檢測機制，等等。

workshop 就是實現了上述多條非同步連線間的負載均衡，健康檢測等。

參考資料

1. 為什麼多 TCP 連線比單 TCP 連線傳輸快

更多原創文章乾貨分享，請關注公眾號