一篇短小的文章,面試經(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)在所有的運(yùn)行時間中只有 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ì)量?比較實(shí)際可用的就是 CodeReview,不要在乎每天多花的那 1 個小時左右的時間,作用可大著呢! 另外,安利這個對提高代碼質(zhì)量有實(shí)際效果的寶貝: sonarqube :保證你寫出更安全更干凈的代碼!(ps: 目前所在的項(xiàng)目基本都會用到這個插件)。 Alibaba 開源的 Java 診斷工具 Arthas 也是很不錯的選擇。 IDEA 自帶的代碼分析等工具進(jìn)行代碼掃描也是非常非常棒的。 2.使用集群,減少單點(diǎn)故障 先拿常用的 Redis 舉個例子!我們?nèi)绾伪WC我們的 Redis 緩存高可用呢?答案就是使用集群,避免單點(diǎn)故障。當(dāng)我們使用一個 Redis 實(shí)例作為緩存的時候,這個 Redis 實(shí)例掛了之后,整個緩存服務(wù)可能就掛了。使用了集群之后,即使一臺 Redis 實(shí)例,不到一秒就會有另外一臺 Redis 實(shí)例頂上。 3.限流 流量控制(flow control),其原理是監(jiān)控應(yīng)用流量的 QPS 或并發(fā)線程數(shù)等指標(biāo),當(dāng)達(dá)到指定的閾值時對流量進(jìn)行控制,以避免被瞬時的流量高峰沖垮,從而保障應(yīng)用的高可用性。——來自 alibaba-Sentinel 的 wiki。 4.超時和重試機(jī)制設(shè)置 一旦用戶請求超過某個時間的得不到響應(yīng),就拋出異常。這個是非常重要的,很多線上系統(tǒng)故障都是因?yàn)闆]有進(jìn)行超時設(shè)置或者超時設(shè)置的方式不對導(dǎo)致的。我們在讀取第三方服務(wù)的時候,尤其適合設(shè)置超時和重試機(jī)制。一般我們使用一些 RPC 框架的時候,這些框架都自帶的超時重試的配置。如果不進(jìn)行超時設(shè)置可能會導(dǎo)致請求響應(yīng)速度慢,甚至導(dǎo)致請求堆積進(jìn)而讓系統(tǒng)無法在處理請求。重試的次數(shù)一般設(shè)為 3 次,再多次的重試沒有好處,反而會加重服務(wù)器壓力(部分場景使用失敗重試機(jī)制會不太適合)。 5.熔斷機(jī)制 超時和重試機(jī)制設(shè)置之外,熔斷機(jī)制也是很重要的。 熔斷機(jī)制說的是系統(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ù)流程進(jìn)行配合,比如用戶在提交訂單之后,不能立即返回用戶訂單提交成功,需要在消息隊(duì)列的訂單消費(fèi)者進(jìn)程真正處理完該訂單之后,甚至出庫后,再通過電子郵件或短信通知用戶訂單成功。除了可以在程序中實(shí)現(xiàn)異步之外,我們常常還使用消息隊(duì)列,消息隊(duì)列可以通過異步處理提高系統(tǒng)性能(削峰、減少響應(yīng)所需時間)并且可以降低系統(tǒng)耦合性。 7.使用緩存 如果我們的系統(tǒng)屬于并發(fā)量比較高的話,如果我們單純使用數(shù)據(jù)庫的話,當(dāng)大量請求直接落到數(shù)據(jù)庫可能數(shù)據(jù)庫就會直接掛掉。使用緩存緩存熱點(diǎn)數(shù)據(jù),因?yàn)榫彺娲鎯υ趦?nèi)存中,所以速度相當(dāng)?shù)乜? 8.其他 核心應(yīng)用和服務(wù)優(yōu)先使用更好的硬件 監(jiān)控系統(tǒng)資源使用情況增加報警設(shè)置。 注意備份,必要時候回滾。 灰度發(fā)布: 將服務(wù)器集群分成若干部分,每天只發(fā)布一部分機(jī)器,觀察運(yùn)行穩(wěn)定沒有故障,第二天繼續(xù)發(fā)布一部分機(jī)器,持續(xù)幾天才把整個集群全部發(fā)布完畢,期間如果發(fā)現(xiàn)問題,只需要回滾已發(fā)布的一部分服務(wù)器即可 定期檢查/更換硬件: 如果不是購買的云服務(wù)的話,定期還是需要對硬件進(jìn)行一波檢查的,對于一些需要更換或者升級的硬件,要及時更換或者升級。 |
免責(zé)聲明:本站部分文章和圖片均來自用戶投稿和網(wǎng)絡(luò)收集,旨在傳播知識,文章和圖片版權(quán)歸原作者及原出處所有,僅供學(xué)習(xí)與參考,請勿用于商業(yè)用途,如果損害了您的權(quán)利,請聯(lián)系我們及時修正或刪除。謝謝!
始終以前瞻性的眼光聚焦站長、創(chuàng)業(yè)、互聯(lián)網(wǎng)等領(lǐng)域,為您提供最新最全的互聯(lián)網(wǎng)資訊,幫助站長轉(zhuǎn)型升級,為互聯(lián)網(wǎng)創(chuàng)業(yè)者提供更加優(yōu)質(zhì)的創(chuàng)業(yè)信息和品牌營銷服務(wù),與站長一起進(jìn)步!讓互聯(lián)網(wǎng)創(chuàng)業(yè)者不再孤獨(dú)!
掃一掃,關(guān)注站長網(wǎng)微信