一篇短小的文章，面試經(jīng)常遇到的這個問題。本文主要包括下面這些內(nèi)容：

　　高可用的定義

　　哪些情況可能會導(dǎo)致系統(tǒng)不可用?

　　有些提高系統(tǒng)可用性的方法?只是簡單的提一嘴，更具體內(nèi)容在后續(xù)的文章中介紹，就拿限流來說，你需要搞懂：何為限流?如何限流?為什么要限流?如何做呢?說一下原理?。

　　什么是高可用?可用性的判斷標(biāo)準(zhǔn)是啥?

　　高可用描述的是一個系統(tǒng)在大部分時間都是可用的，可以為我們提供服務(wù)的。高可用代表系統(tǒng)即使在發(fā)生硬件故障或者系統(tǒng)升級的時候，服務(wù)仍然是可用的。

　　一般情況下，我們使用多少個 9 來評判一個系統(tǒng)的可用性，比如 99.9999% 就是代表該系統(tǒng)在所有的運行時間中只有 0.0001% 的時間都是可用的，這樣的系統(tǒng)就是非常非常高可用的了!當(dāng)然，也會有系統(tǒng)如果可用性不太好的話，可能連 9 都上不了。

　　哪些情況會導(dǎo)致系統(tǒng)不可用?

　　黑客攻擊;

　　硬件故障，比如服務(wù)器壞掉。

　　并發(fā)量/用戶請求量激增導(dǎo)致整個服務(wù)宕掉或者部分服務(wù)不可用。

　　代碼中的壞味道導(dǎo)致內(nèi)存泄漏或者其他問題導(dǎo)致程序掛掉。

　　網(wǎng)站架構(gòu)某個重要的角色比如 Nginx 或者數(shù)據(jù)庫突然不可用。

　　自然災(zāi)害或者人為破壞。

　　......

　　有哪些提高系統(tǒng)可用性的方法?

　　1. 注重代碼質(zhì)量，測試嚴(yán)格把關(guān)

　　我覺得這個是最最最重要的，代碼質(zhì)量有問題比如比較常見的內(nèi)存泄漏、循環(huán)依賴都是對系統(tǒng)可用性極大的損害。大家都喜歡談限流、降級、熔斷，但是我覺得從代碼質(zhì)量這個源頭把關(guān)是首先要做好的一件很重要的事情。如何提高代碼質(zhì)量?比較實際可用的就是 CodeReview，不要在乎每天多花的那 1 個小時左右的時間，作用可大著呢!

　　另外，安利這個對提高代碼質(zhì)量有實際效果的寶貝：

　　sonarqube ：保證你寫出更安全更干凈的代碼!(ps: 目前所在的項目基本都會用到這個插件)。

　　Alibaba 開源的 Java 診斷工具 Arthas 也是很不錯的選擇。

　　IDEA 自帶的代碼分析等工具進行代碼掃描也是非常非常棒的。

　　2.使用集群，減少單點故障

　　先拿常用的 Redis 舉個例子!我們?nèi)绾伪ＷC我們的 Redis 緩存高可用呢?答案就是使用集群，避免單點故障。當(dāng)我們使用一個 Redis 實例作為緩存的時候，這個 Redis 實例掛了之后，整個緩存服務(wù)可能就掛了。使用了集群之后，即使一臺 Redis 實例，不到一秒就會有另外一臺 Redis 實例頂上。

　　3.限流

　　流量控制(flow control)，其原理是監(jiān)控應(yīng)用流量的 QPS 或并發(fā)線程數(shù)等指標(biāo)，當(dāng)達(dá)到指定的閾值時對流量進行控制，以避免被瞬時的流量高峰沖垮，從而保障應(yīng)用的高可用性。——來自 alibaba-Sentinel 的 wiki。

　　4.超時和重試機制設(shè)置

　　一旦用戶請求超過某個時間的得不到響應(yīng)，就拋出異常。這個是非常重要的，很多線上系統(tǒng)故障都是因為沒有進行超時設(shè)置或者超時設(shè)置的方式不對導(dǎo)致的。我們在讀取第三方服務(wù)的時候，尤其適合設(shè)置超時和重試機制。一般我們使用一些 RPC 框架的時候，這些框架都自帶的超時重試的配置。如果不進行超時設(shè)置可能會導(dǎo)致請求響應(yīng)速度慢，甚至導(dǎo)致請求堆積進而讓系統(tǒng)無法在處理請求。重試的次數(shù)一般設(shè)為 3 次，再多次的重試沒有好處，反而會加重服務(wù)器壓力(部分場景使用失敗重試機制會不太適合)。

　　5.熔斷機制

　　超時和重試機制設(shè)置之外，熔斷機制也是很重要的。 熔斷機制說的是系統(tǒng)自動收集所依賴服務(wù)的資源使用情況和性能指標(biāo)，當(dāng)所依賴的服務(wù)惡化或者調(diào)用失敗次數(shù)達(dá)到某個閾值的時候就迅速失敗，讓當(dāng)前系統(tǒng)立即切換依賴其他備用服務(wù)。 比較常用的是流量控制和熔斷降級框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。

　　6.異步調(diào)用

　　異步調(diào)用的話我們不需要關(guān)心最后的結(jié)果，這樣我們就可以用戶請求完成之后就立即返回結(jié)果，具體處理我們可以后續(xù)再做，秒殺場景用這個還是蠻多的。但是，使用異步之后我們可能需要 適當(dāng)修改業(yè)務(wù)流程進行配合，比如用戶在提交訂單之后，不能立即返回用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單之后，甚至出庫后，再通過電子郵件或短信通知用戶訂單成功。除了可以在程序中實現(xiàn)異步之外，我們常常還使用消息隊列，消息隊列可以通過異步處理提高系統(tǒng)性能(削峰、減少響應(yīng)所需時間)并且可以降低系統(tǒng)耦合性。

　　7.使用緩存

　　如果我們的系統(tǒng)屬于并發(fā)量比較高的話，如果我們單純使用數(shù)據(jù)庫的話，當(dāng)大量請求直接落到數(shù)據(jù)庫可能數(shù)據(jù)庫就會直接掛掉。使用緩存緩存熱點數(shù)據(jù)，因為緩存存儲在內(nèi)存中，所以速度相當(dāng)?shù)乜?

　　8.其他

　　核心應(yīng)用和服務(wù)優(yōu)先使用更好的硬件

　　監(jiān)控系統(tǒng)資源使用情況增加報警設(shè)置。

　　注意備份，必要時候回滾。

　　灰度發(fā)布： 將服務(wù)器集群分成若干部分，每天只發(fā)布一部分機器，觀察運行穩(wěn)定沒有故障，第二天繼續(xù)發(fā)布一部分機器，持續(xù)幾天才把整個集群全部發(fā)布完畢，期間如果發(fā)現(xiàn)問題，只需要回滾已發(fā)布的一部分服務(wù)器即可

　　定期檢查/更換硬件： 如果不是購買的云服務(wù)的話，定期還是需要對硬件進行一波檢查的，對于一些需要更換或者升級的硬件，要及時更換或者升級。