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

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

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

1、流量控制

在即時消息系統中，突發超高流量時，爲了不服務器總體被流量打死，咱們能夠經過流控來扔掉或者經過排隊的方式來保護系統在能力範圍內的運轉。

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

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

2、熔斷機制

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

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

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

3、總結

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

後記

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