可以采用哪些解決方案？

01什么是高可用性？首先，我們需要理解什么是高可用？維基百科的定義如下：高可用性（英語：High Availability，縮寫為 HA），IT術語，指系統無中斷地執行其功能的能力，代表系統的可用性程度。是進行系統設計時的準則之一。基本上來說，就是要讓我們的計算環境（包括軟硬件）做到full-time的可用性。在架構上來說，需要考慮如下設計：1. 對軟硬件的冗余，以消除單點故障。任何系統都會有一個或多個冗余系統做standby。

2. 對故障的檢測和恢復。檢測故障以及用備份的結點接管故障點。這也就是failover。

02 高可用的三種模式1、主備模式 主節點工作，備節點處于監控準備狀況；當主節點宕機時，備節點接管主節點的一切工作；待主節點恢復正常后，有兩種恢復方式，一種是自動或手動方式切回到主節點；另一種是不切回，以前的主機淪為備節點，這種方式一般在云端采用。數據的一致性一般是通過數據庫同步方式解決。案例：天翼云/華為云MySQL數據庫服務的主備實例，如下圖所示：

2、雙活模式

主節點和備節點同時運行，通過全局負載均衡器負載分攤訪問流量，當主節點機宕機時，備節點機立即接管它的一切工作，保證系統不間斷運行；主備節點一般是共享主節點的數據庫實例，備節點數據庫實例同步主節點實例，可提供只讀服務。案例：招商局的同城雙活災備系統就是該模式，可參考鏈接：百年招商局大轉型，“雙云”混合繼往開來

http://www.sohu.com/a/225597241_122592

3、集群模式

多個節點構成集群，一起工作，有如下特點：多主架構，去中心化；集群不同節點之間數據實時同步，沒有延遲；在出現數據庫故障時，因支持多點寫入，切換容易；在服務期間，可支持節點增加或刪除的“熱插拔”；集群的維護，對應用程序是透明的。案例：天翼云/華為云分布式緩存集群實例，其架構圖如下所示：

所有的redis節點彼此互聯；客戶端與redis節點直連,不需要中間proxy層；客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可。

03 IT基礎設施的高可用1、網絡高可用由于網絡存儲的快速發展，網絡冗余技術被不斷提升，提高IT系統的高可用性的關鍵應用就是網絡高可用性，網絡高可用性是通過匹配冗余的網絡設備實現網絡設備的冗余，達到高可用的目的。比如冗余的交換機，冗余的路由器等2、服務器高可用服務器高可用主要使用的是服務器集群軟件或高可用軟件來實現。3、存儲高可用

使用軟件或硬件技術實現存儲的高度可用性。其主要技術指標是存儲切換功能，數據復制功能，數據快照功能等。當一臺存儲出現故障時，另一臺備用的存儲可以快速切換，達一存儲不停機的目的。

04 高可用性的度量系統可用性一般用n個9來度量，9越多代表全年服務可用時間越長服務更可靠，停機時間越短，反之亦然。

下表提供了n個9對應的年、月、周、天的宕機時間：

宕機時間是怎么計算的呢？宕機時間顧名思義就是不可用時間，比如，可用性為99.999%（5個9），不可用性為1-99.999%=0.001%，我們算一下按照“年”來度量的宕機時間如下：365天*24小時*60分鐘*（1-99.999%）≈5.26分/年。可信云官網列出的天翼云主機的業務可用性指標為99.95%，我們計算一下宕機時間：365天*24小時*（1-99.95%）≈4.38小時/年。

在線系統和執行關鍵任務的系統，比如金融系統，通常要求其可用性要達到5個9標準(99.999%)。

05 數據一致性問題高可用系統，細節之處全是魔鬼，冗余結點最大的難題就是數據復制的數據一致性保證。冗余數據所帶來的一致性問題是魔鬼中的魔鬼：如果主備節點數據復制是異步的，那么在failover的時候就會出現數據差異的情況。如果主備節點數據復制是同步的，那么就會導致冗余結點越多性能越慢。

所以，很多高可用系統都是在做各種取舍，如果我們對數據庫的性能要求較高，能容忍一定的數據差異，建議采用異步復制模式；如果要求數據的強一致性，能夠容忍一定的性能損耗，建議采用同步復制模式，比如銀行賬號的余額真實體現了賬戶的結余，不能允許主備節點賬號余額不一致，此時就必需做到強一致性。

06 高可用性總結要做到服務高可用，就必需要有備用（復本），無論是應用結點還是數據結點要做到復制，就會有數據一致性的問題，要根據業務場景來取舍我們不可能做到100%的高可用，也就是說，我們能做到幾個9個的SLA我們很難計算出系統有多少的可用性，因為影響一個系統的因素實在是太多了，除了軟件設計，還有硬件，還有第三方的服務（如電信聯通的寬帶SLA），當然包括“建筑施工隊的挖掘機”。要真正保障系統的高可用性，是一件很難的事情，就算是3個9的可用性，一個月的宕機時間也只有40多分鐘，即使是排名靠前的云服務商，也經常需要人肉處理故障， 一個故障處理1個多小時甚至2-3個小時，也是正常情況，當云服務商在官網上聲明自己的SLA是3個9或是5個9，要切實提高自己的自動化運維處理故障的能力，不然客戶會拿著官網的SLA來索賠。