非不定高
1 一個公式
高可用方案千變萬化，但是萬變不離其宗。高可用核心公式如下：
高可用 = 冗餘 + 自動故障轉移 + 降級 + 隔離
2 兩種思路
我們來思考一個問題，怎樣保證一個工程系統的穩定性？有以下兩種做法：
思路1：考慮到所有意外情況，針對每一個意外的異常情況分別處理。
思路2：接受無法預料到所有意外情況的現實，把兜底方案做好，保證即使出現極端情況，系統也不會崩潰。
3 反脆弱
我們仔細分析思路1，會發現這其實是一個悖論。
所謂意外情況，就是意料之外的情況，無法預料的情況。如果被考慮到了，那麼也就不能稱之為意外情況了。
塔勒布在經典著作《反脆弱》一直想告訴我們的是，黑天鵝事件是無法預測的，極端的意外情況是無法預測的，尾部風險雖然概率微小，但是破壞力卻極大。
我們能做的就是保護好系統，讓系統在極端情況下不要崩潰。
4 冗餘
冗餘又分冷備份和熱備份。我們以數據庫為例。
冷備份是指定時將數據庫的數據備份，歸檔，供後續查閱和校對。
熱備份最常見的就是主從模式。主從數據實時同步，一來可以做讀寫分離，提高訪問效率，二來當主庫宕機，從庫可以頂上去繼續提供服務。
5 自動故障轉移
繼續以數據庫為例。當主庫宕機，肯定不能人工去切換成備庫，這樣對故障處理的響應時間肯定會增加，而應該自動切換為備庫。
這樣的例子還有很多，比如當nginx掛時keepalived能夠探測到會自動的進行故障轉移，Redis中的哨兵機制。
6 降級
所謂降級策略，就是當系統遇到無法承受的壓力時，選擇暫時關閉一些非關鍵的功能，或者延時提供一些功能，把此刻所有的資源都提供給現在最關鍵的服務。
在秒殺場景中，下訂單就是最核心最關鍵的功能。當系統壓力將要到達臨界值時，可以暫時先關閉一些非核心功能如查詢功能。
還有一種降級策略，當系統依賴的下游服務出現錯誤，甚至下游服務已經完全不可用了，那麼此時就不能再調用這個下游服務了，否則可能導致雪崩。所以直接返回兜底方案，把下游服務直接降級。
7 隔離
物理隔離：兩個應用分別部署在不同的物理機、不同的機房，資源不會互相影響。
線程隔離：不同的請求進行分類，交給不同的線程池處理，當一類請求出現高耗時和異常，不影響另一類請求的訪問。
8 孫子兵法
備前則後寡，備後則前寡，備左則右寡，備右則左寡，無所不備，則無所不寡。
力量集中在前，後面就空虛。力量集中在後，前面就空虛。力量集中在左，右面就空虛。力量集中在右，左面就空虛。力量分散在前後左右，那麼前後左右就都空虛。
不確定性分散在前後左右，無法預測。
我們不可能將精力分散在前後左右，但至少可以做好一點：保護好系統。
敬請關注
請點擊關注按鈕【IT徐胖子】會持續為大家奉獻互聯網和技術乾貨內容，感謝支持
IT徐胖子
提高系統可用性最簡單的方法就是“加資源”，4C16G 變 8C32G，但是單體機器的資源畢竟有限，而分佈式架構的實質，就是讓多臺機器，甚至是海量機器，合作完成一件事情，提高分佈式系統的高可用性，可以從以下幾個方面入手。
在分佈式架構中單點意味著風險，一定要儘可能地避免單點故障。
01. 利用負載均衡，進行集群化部署
負載均衡可以將請求平均地分配給每一臺服務器，能夠利用多臺機器的資源，更重要的是，當一臺機器發生故障時，不會影響整個系統的使用；這裡要注意要有一定的冗餘，否則可能會導致一臺機器發生故障，剩下的機器無法抗住壓力導致整個系統的崩潰。
02. 橫向擴容，彈性擴容縮容
上面也說到，集群環境下一臺服務器的異常可能會導致整個系統的崩潰，如果能做到彈性擴容鎖容的話，可以大大提高系統的高可用性；當流量增大的時候，增加幾臺服務器，當流量降下去，減少幾臺服務器，這一切都是自動完成的。
03. 灰度發佈，快速回滾
儘管有測試人員進行測試，但是依然很難覆蓋所有的使用場景，為了避免出現生產環境大範圍的故障或BUG，所以我們一般會採用灰度發佈，也就是讓一部分用戶可以用到這個新功能，驗證無誤後再擴大應用範圍，直到所有的應用都更新完成，如果在驗證的過程中發現問題，那麼就快速回滾。
04. 垂直切分
橫向伸縮，是將相同的應用部署多套，或者相同的數據存儲多份，而垂直切分，是將一個大系統切分成多個小系統、微服務，數據分庫分表，以前是一掛全部都掛，現在出現故障，可能只是部分業務功能不可用。
05. 對突發流量的容錯能力
如果系統的用戶量固定，併發量可估且平穩，那麼一切都可控，但是應用如果是面向互聯網用戶的，那麼對於未知的徒增流量就要有應對策略，常用的做法有限流、熔斷、降級；限流只讓部分流量進入系統，拒絕掉多餘的流量保護系統；熔斷就是保險絲，在發生短路的時候自動跳閘，保護系統；降級是當流量徒增，可以限制不重要的系統或服務的訪問量，保護主要業務。
06. 系統監控和預警
分佈式系統發生故障不可怕，錯誤定位困難和恢復時間長才可怕，所以分佈式系統需要有完善的監控系統，在系統可能發生故障的時候，及時預警，在真正發生故障後，準確定位故障，方便運維人員修復。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
高可用性確實是分佈式系統一項重要的指標，跟數據一致性，分區容錯性組成了分佈式系統的CAP原則，本文只針對高可用性分析如下：
高可用性：High Availability，保證分佈式系統在較長的時間內能正常響應，持續可用，業界常用幾個9的說法來說明高可用性，比如說5個9，就是99.999%，全年只能停機幾十分鐘而已！
毫無疑問，單點的系統是無論如何也不可能實現高可用的，因為受到單點故障，服務發佈，網絡延遲等原因，客戶端總會接收不到響應，即服務不可用！
比如數據庫常用的集群手段有：
1，主從複製，讀寫分離：不能做到高可用，如果主機掛了，整個系統的寫功能就不能用了！
2，分庫分表：不能做到高可用，分庫分表是把所有的數據分佈到了很多的分庫中，其中一個分庫掛了，這部分數據就沒了！
3，雙主互備：可以做到高可用，雙主機數據一致，能動態切換主庫，其中一臺壞了，另一臺可提供使用！
雙主互備得到的集群雖然實現了高可用，由於雙機數據一致，限制了整個集群的容量！
分佈式服務的高可用更加的複雜，因為分佈式系統對外是一個整體，換句話說分佈式的高可用需要保證分佈式系統中包括應用系統，數據庫，緩存系統，消息組件等所有服務的高可用性！
高可用性的解決方法一般來說比較單一，包括數據冗餘，故障熔斷，服務轉移！
數據冗餘保證在任何時候最新的數據都不丟失，多份數據冗餘也為後期的數據還原提供基礎！
故障熔斷，服務轉移保證單個服務不可用時，使用熔斷防止服務不可用影響別的服務，並使用最新的健康服務以替換！
針對應用系統的單點，一定要壓測出最大的容納能力，同時可以使用負載均衡的方式搭建集群，服務還應該設計為冪等的，防止數據一致性問題！
高可用性解決方案貌似除了堆機器，沒有更好的辦法，不知道大家有什麼手段，寫出來讓大家學習學習！
此生唯一
高可用最樸素的意思就是，服務部署在多臺機器上組成一個服務集群，這樣其中某臺出現了問題，服務還可以繼續對外提供服務，CAP是分佈式高可用的必懂定理，如果服務是有狀態的服務，需要考慮服務狀態的一致性。不過現在都是強調強一致性。
騎車的土撥鼠
多考慮數據狀態的同步。
zhangyiant
高可用性的前提是：保證服務系統能夠持續工作，實現高可用性一般有兩種手段： 一種是通過第三方軟件／組件保證系統的可用性；另一種是軟件／組件自身己具備高可用的技術實現。
