版權聲明:本文由吳逸翔 原創文章,轉載請註明出處:
文章原文連接:https://www.qcloud.com/community/article/538713001487764019web
來源:騰雲閣 https://www.qcloud.com/community算法
有個朋友的web服務,由於在線用戶數目日常波動很大,按照最大在線數部署服務器顯然太浪費,因此選擇了騰訊雲的彈性伸縮(AutoScaling)服務,在天天用戶集中上線的時間點上快速擴容服務器加入到集羣中分散壓力。所以在集羣遭遇到突發的訪問壓力的時候,快速的自動擴容能力就顯得很是重要了。前陣子還專門爲此請教了騰訊雲專家,解析了快速生成主機的不傳之祕 。服務器
可是快速生成了主機並加入集羣,並不能確保主機快速的分擔壓力,由於騰訊雲的負載均衡目前只支持IP hash 和按權重輪詢兩種方式,這兩種分配算法在新服務器加入後都須要通過一段短期的預熱才能逐步分配到流量。所以擴容後的曲線經常會是這樣子的(剛剛進行的擴容實測,爲了下降對業務影響測試了5分鐘就停掉了):
注意紅色曲線和橫軸重合的部分:
(第一分鐘0Mbps)
(第二分鐘0Mbps)
(第三分鐘0Mbps)負載均衡
也就是說,雖然生成一臺服務器咱們能夠優化到數十秒,可是新服務器加入集羣后的前面幾分鐘幾乎沒有請求分發到新服務器上,隨後才步入正軌。這樣顯然延長了壓力緩解過程,讓更多用戶忍受了幾分鐘的惡劣體驗。測試
那有沒有辦法縮短這個過程呢?騰訊雲近期將推出的新的負載均衡輪詢算法就能夠解決這個問題。新算法被稱爲「最小鏈接數」算法,也就是LB會隨時判斷哪臺主機上的HTTP鏈接數最少,而後儘可能把新的請求分發給它。通過一番軟磨硬泡,終於從負載均衡團隊磨到了新LB算法的內測體驗資格,馬上作了一個擴容實驗。咱們來看看效果:優化
能夠看到,最開始和橫軸重合的一段消失了,新服務器在接入的第一時間馬上分攤到了訪問量並輸出流量,集羣中過載的服務器壓力也就馬上獲得了緩解。spa
不僅是擴容過程會重新算法中收益,實際上在以往的算法中,集羣中的服務器都難以即時分擔彼此的壓力,當某一臺或者幾臺服務器壓力過大的時候,LB只會繼續按照權重隨機的分配新的請求給它,而不是下降它的權重,讓它緩一緩。而在新算法中,若是一臺服務器負擔壓力太重致使請求沒法及時響應完成,LB就會觀察到它的鏈接數增長,並把更多的請求分配給鏈接數更少的服務器,從而達到更優的負載均衡效果。3d
固然,要充分得到這些優點都要取決於接入服務器已經實現了『無狀態化』這個前提,不然負載均衡也沒法隨意的把一臺服務器的壓力轉移到另外一臺上面。blog