IM 系統的不可用主要有以下兩個原因： 一是無法預測突發流量，即使進行了服務拆分、自動擴容，但流量增長過快時，服務已經不可用了； 二是業務中依賴的這些介面、資源不可用或變慢時，比如發訊息可能需要依賴“垃圾內容識別”的 API 來進行訊息內容的過濾，下推圖片訊息可能需要依賴圖片服務獲取縮圖來進行推流，會導致業務整體失敗或者被拖慢而造成超時，影響服務的整體可用性。 如何保證系統的高可用呢？ #### 一、流量控制 在即時訊息系統中，突發超高流量時，為了避免伺服器整體被流量打死，我們可以通過流控來扔掉或者通過排隊的方式來保護系統在能力範圍內的運轉。 流控演算法主要有**漏桶演算法**和**令牌桶演算法**。 | 漏桶演算法 | 令牌桶演算法 | | --- | --- | | 漏桶演算法比較形象，把請求比作是水，水來了都先放進桶裡，並以限定的速度出水，當水來得過猛而出水不夠快時就會導致水直接溢位，即拒絕服務。 | 令牌桶演算法控制的是一個時間視窗內通過的資料量，以恆定的速率產生令牌，然後把令牌放到令牌桶中。來一個請求，就會從令牌桶中取出一個令牌，如果此時令牌桶中沒有令牌，則拒絕該請求或等待新的令牌放入桶中。若令牌桶滿了，則新令牌會被丟棄，不再放入桶中。| |  | | | 漏桶演算法通過控制資料注入到網路的速率，平滑網路上的突發流量。 | 令牌桶演算法能夠在限制資料的平均傳輸速率的同時還允許某種程度的突發傳輸。 | #### 二、熔斷機制 當下遊服務因訪問壓力過大而響應變慢或失敗，依賴於下游的上游服務也會受到影響，出現整體效能被拖累變慢的情況，最終可能導致系統整體效能的雪崩。這種當下遊服務出問題時，為了保護系統整體的可用性而暫時切斷對下游服務的呼叫的行為就是“熔斷”。 自動熔斷機制主要通過持續收集被依賴服務或者資源的訪問資料和效能指標，當效能出現一定程度的惡化或者失敗量達到某個閾值時，會自動觸發熔斷，讓當前依賴快速失敗（Fail-fast），並降級到其他備用依賴，或者暫存到其他地方便於後續重試恢復。在熔斷過程中，再通過不停探測被依賴服務或者資源是否恢復，來判斷是否自動關閉熔斷，恢復業務。 > 關於“熔斷”，可以看這篇部落格文章，寫得很形象：[分散式系統關注點\(8\)——99%的人都能看懂的「熔斷」以及最佳實踐](https://www.cnblogs.com/Zachary-Fan/p/9976197.html) #### 三、總結 限流、熔斷機制和快取，是應對系統高併發、保證系統高可用的有效利器。 #### 後記 這篇文章於我的意義更多的是拓寬我的知識層面，讓我不至於那麼孤陋