一篇短小的文章，面試經常遇到的這個問題。本文主要包括下面這些內容：

　　高可用的定義

　　哪些情況可能會導致系統不可用?

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

　　什么是高可用?可用性的判斷標準是啥?

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

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

　　哪些情況會導致系統不可用?

　　黑客攻擊;

　　硬件故障，比如服務器壞掉。

　　并發量/用戶請求量激增導致整個服務宕掉或者部分服務不可用。

　　代碼中的壞味道導致內存泄漏或者其他問題導致程序掛掉。

　　網站架構某個重要的角色比如 Nginx 或者數據庫突然不可用。

　　自然災害或者人為破壞。

　　......

　　有哪些提高系統可用性的方法?

　　1. 注重代碼質量，測試嚴格把關

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

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

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

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

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

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

　　先拿常用的 Redis 舉個例子!我們如何保證我們的 Redis 緩存高可用呢?答案就是使用集群，避免單點故障。當我們使用一個 Redis 實例作為緩存的時候，這個 Redis 實例掛了之后，整個緩存服務可能就掛了。使用了集群之后，即使一臺 Redis 實例，不到一秒就會有另外一臺 Redis 實例頂上。

　　3.限流

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

　　4.超時和重試機制設置

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

　　5.熔斷機制

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

　　6.異步調用

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

　　7.使用緩存

　　如果我們的系統屬于并發量比較高的話，如果我們單純使用數據庫的話，當大量請求直接落到數據庫可能數據庫就會直接掛掉。使用緩存緩存熱點數據，因為緩存存儲在內存中，所以速度相當地快!

　　8.其他

　　核心應用和服務優先使用更好的硬件

　　監控系統資源使用情況增加報警設置。

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

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

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