本文已經收錄自筆者開源的 JavaGuide: https://github.com/Snailclimb (69k+Star【Java學習+面試指南】 一份涵蓋大部分Java程式設計師所需要掌握的核心知識)如果覺得不錯的還，不妨去點個Star，鼓勵一下!

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

1. 高可用的定義
2. 哪些情況可能會導致系統不可用？
3. 有些提高系統可用性的方法？只是簡單的提一嘴，更具體內容在後續的文章中介紹，就拿限流來說，你需要搞懂：何為限流？如何限流？為什麼要限流？如何做呢？說一下原理？。

什麼是高可用？可用性的判斷標準是啥？

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

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

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

1. 黑客攻擊；
2. 硬體故障，比如伺服器壞掉。
3. 併發量/使用者請求量激增導致整個服務宕掉或者部分服務不可用。
4. 程式碼中的壞味道導致記憶體洩漏或者其他問題導致程式掛掉。
5. 網站架構某個重要的角色比如 Nginx 或者資料庫突然不可用。
6. 自然災害或者人為破壞。
7. ......

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

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

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

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

1. sonarqube ：保證你寫出更安全更乾淨的程式碼！（ps: 目前所在的專案基本都會用到這個外掛）。
2. Alibaba 開源的 Java 診斷工具 Arthas 也是很不錯的選擇。
3. 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.其他

1. 核心應用和服務優先使用更好的硬體
2. 監控系統資源使用情況增加報警設定。
3. 注意備份，必要時候回滾。
4. 灰度釋出： 將伺服器叢集分成若干部分，每天只發布一部分機器，觀察執行穩定沒有故障，第二天繼續釋出一部分機器，持續幾天才把整個叢集全部發布完畢，期間如果發現問題，只需要回滾已釋出的一部分伺服器即可
5. 定期檢查/更換硬體： 如果不是購買的雲服務的話，定期還是需要對硬體進行一波檢查的，對於一些需要更換或者升級的硬體，要及時更換或者升級。
6. .....(想起來再補充！也歡迎各位歡迎補充！)

總結

相關推薦