作者簡介：曾任職於阿里巴巴，每日優鮮等網際網路公司，任技術總監，15年電商網際網路經歷。
關於熔斷，網上的文章很多，但是真正講明白的文章寥寥無幾。很多作者互相抄襲，缺乏自己的認知和理解。
分享熔斷之前，咱們先說說大家更熟悉的timeout。timeout和熔斷有關係嗎？別急，往下看就清楚啦！
我們在跨系統呼叫、跨服務呼叫以及呼叫第三方介面時，一般會設定超時時間。有兩個作用：其一，出於使用者體驗考慮，啥結果也不返回，一直讓人等下去，確實受不了。其二，出於系統效能問題的考慮，併發不高時timeout可以避免執行緒阻塞帶來的效能問題，但是併發高時timeout就不能解決問題啦。
現在輪到熔斷大顯身手了。
熔斷是什麼？
一種降級手段。當服務不可用時，用來避免連鎖故障，雪崩效應。發生在服務呼叫的時候，在呼叫方做熔斷處理。
熔斷的意義是什麼？
我們使用熔斷前要先弄清楚熔斷的真正意義，避免用錯給系統帶來麻煩。實際上，用一句話就可以描述熔斷的意義：上游服務快速失敗（fail fast），並保護下游服務。
詳細解釋一下，假設上游服務是a，下游服務是b，a呼叫b，b發生故障，開啟熔斷：
熔斷狀態流轉過程：
假設上游服務是a，下游服務是b，a呼叫b。
熔斷生命週期包括三個狀態：關閉，半開啟，開啟。
關閉狀態->開啟狀態，a呼叫b請求失敗次數在設定時間內達到閾值，開啟熔斷
開啟狀態->半開啟狀態，熔斷開啟後，熔斷器根據設定時間間隔定期自動進入半開啟狀態
半開啟狀態->關閉狀態（或開啟狀態），半開啟狀態下會從a傳送少量請求到b來試探b服務是否能正常提供服務，如果請求成功率達到閾值就關閉熔斷，否則就回到熔斷開啟狀態
熔斷適用場景
出於系統效能問題的考慮，併發不高時timeout可以避免執行緒阻塞帶來的效能問題，但是併發高時timeout就不能解決問題啦。這時可以用熔斷。
只要是服務之間的呼叫，並且能設計合理的獲取返回值的方案（返回值可以是預設值，或者通過一種後備（fallback）方案獲取的值），一般業務場景都可以做熔斷處理。比如電商行業，在sku不是很多的場景下，我們可以在訂單服務冗餘庫存資料（注意控制合理的安全庫存，防超賣）。下單減庫存時，如果庫存服務掛了，開啟熔斷後，我們可以直接從訂單服務取庫存，訂單服務取不到庫存，按扣減庫存失敗處理。這個可以做為後備（fallback）方案。
有哪些開源實現
hystrix，resilience4j等
如有收穫，點個在看，誠摯感謝
TiDB 的適用場景和不適用場景
典型的oltp場景 當您需要對海量資料 數十億行 進行隨機 實時讀 寫訪問時 實時 htap 場景 實時htap 混合事務 分析處理 要是有乙個使用tidb的類似oltp的場景，並且希望在tiflash的幫助下原地進行 olap分析時，新鮮的資料，對oltp效能無干擾 資料整合 有多個資料來源時，可...
mongodb適用和不適用的應用場景
近期考慮把訂單歷史資料從oracle資料庫遷移到nosql資料庫做歷史資料查詢和分析，一天千萬級資料。打算使用mongodb資料庫。使用nodejs做查詢和統計api，對併發請求量要求低，不知道有沒有前輩這樣玩過。我們如今僅僅用mongodo儲存日誌資料，做應用故障分析用。假設有前輩做個類似的歷史庫...
MongoDB的特點和適用場景
mongodb的特點和適用場景實用性 mongodb是乙個面向文件的資料庫，它並不是關係型資料庫，直接訪問bson，這意味著mongodb更加靈活，因為可以在文件中直接插入陣列之類的複雜資料型別，並且文件的key和value不是固定的資料型別和大小，所以開發者在使用mongodb時無須預定義關係型資...