《即時消息技術剖析與實戰》學習筆記11——IM系統如何保證服務高可用

• 2020 年 3 月 7 日
• 筆記

IM 系統的不可用主要有以下兩個原因：
一是無法預測突發流量，即使進行了服務拆分、自動擴容，但流量增長過快時，服務已經不可用了；
二是業務中依賴的這些接口、資源不可用或變慢時，比如發消息可能需要依賴「垃圾內容識別」的 API 來進行消息內容的過濾，下推圖片消息可能需要依賴圖片服務獲取縮略圖來進行推流，會導致業務整體失敗或者被拖慢而造成超時，影響服務的整體可用性。

如何保證系統的高可用呢？

一、流量控制

在即時消息系統中，突發超高流量時，為了避免服務器整體被流量打死，我們可以通過流控來扔掉或者通過排隊的方式來保護系統在能力範圍內的運轉。

流控算法主要有漏桶算法和令牌桶算法。

漏桶算法	令牌桶算法
漏桶算法比較形象，把請求比作是水，水來了都先放進桶里，並以限定的速度出水，當水來得過猛而出水不夠快時就會導致水直接溢出，即拒絕服務。	令牌桶算法控制的是一個時間窗口內通過的數據量，以恆定的速率產生令牌，然後把令牌放到令牌桶中。來一個請求，就會從令牌桶中取出一個令牌，如果此時令牌桶中沒有令牌，則拒絕該請求或等待新的令牌放入桶中。若令牌桶滿了，則新令牌會被丟棄，不再放入桶中。
漏桶算法通過控制數據注入到網絡的速率，平滑網絡上的突發流量。	令牌桶算法能夠在限制數據的平均傳輸速率的同時還允許某種程度的突發傳輸。

二、熔斷機制

當下游服務因訪問壓力過大而響應變慢或失敗，依賴於下游的上游服務也會受到影響，出現整體性能被拖累變慢的情況，最終可能導致系統整體性能的雪崩。這種當下游服務出問題時，為了保護系統整體的可用性而暫時切斷對下游服務的調用的行為就是「熔斷」。

自動熔斷機制主要通過持續收集被依賴服務或者資源的訪問數據和性能指標，當性能出現一定程度的惡化或者失敗量達到某個閾值時，會自動觸發熔斷，讓當前依賴快速失敗（Fail-fast），並降級到其他備用依賴，或者暫存到其他地方便於後續重試恢復。在熔斷過程中，再通過不停探測被依賴服務或者資源是否恢復，來判斷是否自動關閉熔斷，恢復業務。

關於「熔斷」，可以看這篇博客文章，寫得很形象：分佈式系統關注點(8)——99%的人都能看懂的「熔斷」以及最佳實踐

三、總結

限流、熔斷機制和緩存，是應對系統高並發、保證系統高可用的有效利器。

後記

這篇文章於我的意義更多的是拓寬我的知識層面，讓我不至於那麼孤陋寡聞?