摘要:假設(shè)反向代理層是,里能夠配置多個(gè)后端,并且能夠探測(cè)到多個(gè)后端的存活性。以為例,天然支持主從同步,官方也有哨兵機(jī)制,來做的存活性檢測(cè)。方法論上,高可用是通過冗余自動(dòng)故障轉(zhuǎn)移來實(shí)現(xiàn)的。
究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高可用” 一、什么是高可用
高可用HA(High Availability)是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一,它通常是指,通過設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間。
假設(shè)系統(tǒng)一直能夠提供服務(wù),我們說系統(tǒng)的可用性是100%。
如果系統(tǒng)每運(yùn)行100個(gè)時(shí)間單位,會(huì)有1個(gè)時(shí)間單位無法提供服務(wù),我們說系統(tǒng)的可用性是99%。
很多公司的高可用目標(biāo)是4個(gè)9,也就是99.99%,這就意味著,系統(tǒng)的年停機(jī)時(shí)間為8.76個(gè)小時(shí)。
百度的搜索首頁,是業(yè)內(nèi)公認(rèn)高可用保障非常出色的系統(tǒng),甚至人們會(huì)通過www.baidu.com 能不能訪問來判斷“網(wǎng)絡(luò)的連通性”,百度高可用的服務(wù)讓人留下啦“網(wǎng)絡(luò)通暢,百度就能訪問”,“百度打不開,應(yīng)該是網(wǎng)絡(luò)連不上”的印象,這其實(shí)是對(duì)百度HA最高的褒獎(jiǎng)。
我們都知道,單點(diǎn)是系統(tǒng)高可用的大敵,單點(diǎn)往往是系統(tǒng)高可用最大的風(fēng)險(xiǎn)和敵人,應(yīng)該盡量在系統(tǒng)設(shè)計(jì)的過程中避免單點(diǎn)。方法論上,高可用保證的原則是“集群化”,或者叫“冗余”:只有一個(gè)單點(diǎn),掛了服務(wù)會(huì)受影響;如果有冗余備份,掛了還有其他backup能夠頂上。
保證系統(tǒng)高可用,架構(gòu)設(shè)計(jì)的核心準(zhǔn)則是:冗余。
有了冗余之后,還不夠,每次出現(xiàn)故障需要人工介入恢復(fù)勢(shì)必會(huì)增加系統(tǒng)的不可服務(wù)實(shí)踐。所以,又往往是通過“自動(dòng)故障轉(zhuǎn)移”來實(shí)現(xiàn)系統(tǒng)的高可用。
接下來我們看下典型互聯(lián)網(wǎng)架構(gòu)中,如何通過冗余+自動(dòng)故障轉(zhuǎn)移來保證系統(tǒng)的高可用特性。
常見互聯(lián)網(wǎng)分布式架構(gòu)如上,分為:
(1)客戶端層:典型調(diào)用方是瀏覽器browser或者手機(jī)應(yīng)用APP
(2)反向代理層:系統(tǒng)入口,反向代理
(3)站點(diǎn)應(yīng)用層:實(shí)現(xiàn)核心應(yīng)用邏輯,返回html或者json
(4)服務(wù)層:如果實(shí)現(xiàn)了服務(wù)化,就有這一層
(5)數(shù)據(jù)-緩存層:緩存加速訪問存儲(chǔ)
(6)數(shù)據(jù)-數(shù)據(jù)庫(kù)層:數(shù)據(jù)庫(kù)固化數(shù)據(jù)存儲(chǔ)
整個(gè)系統(tǒng)的高可用,又是通過每一層的冗余+自動(dòng)故障轉(zhuǎn)移來綜合實(shí)現(xiàn)的。
【客戶端層->反向代理層】的高可用
【客戶端層】到【反向代理層】的高可用,是通過反向代理層的冗余來實(shí)現(xiàn)的。以nginx為例:有兩臺(tái)nginx,一臺(tái)對(duì)線上提供服務(wù),另一臺(tái)冗余以保證高可用,常見的實(shí)踐是keepalived存活探測(cè),相同virtual IP提供服務(wù)。
自動(dòng)故障轉(zhuǎn)移:當(dāng)nginx掛了的時(shí)候,keepalived能夠探測(cè)到,會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移,將流量自動(dòng)遷移到shadow-nginx,由于使用的是相同的virtual IP,這個(gè)切換過程對(duì)調(diào)用方是透明的。
【反向代理層->站點(diǎn)層】的高可用
【反向代理層】到【站點(diǎn)層】的高可用,是通過站點(diǎn)層的冗余來實(shí)現(xiàn)的。假設(shè)反向代理層是nginx,nginx.conf里能夠配置多個(gè)web后端,并且nginx能夠探測(cè)到多個(gè)后端的存活性。
自動(dòng)故障轉(zhuǎn)移:當(dāng)web-server掛了的時(shí)候,nginx能夠探測(cè)到,會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移,將流量自動(dòng)遷移到其他的web-server,整個(gè)過程由nginx自動(dòng)完成,對(duì)調(diào)用方是透明的。
【站點(diǎn)層->服務(wù)層】的高可用
【站點(diǎn)層】到【服務(wù)層】的高可用,是通過服務(wù)層的冗余來實(shí)現(xiàn)的?!胺?wù)連接池”會(huì)建立與下游服務(wù)多個(gè)連接,每次請(qǐng)求會(huì)“隨機(jī)”選取連接來訪問下游服務(wù)。
自動(dòng)故障轉(zhuǎn)移:當(dāng)service掛了的時(shí)候,service-connection-pool能夠探測(cè)到,會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移,將流量自動(dòng)遷移到其他的service,整個(gè)過程由連接池自動(dòng)完成,對(duì)調(diào)用方是透明的(所以說RPC-client中的服務(wù)連接池是很重要的基礎(chǔ)組件)。
【服務(wù)層>緩存層】的高可用
【服務(wù)層】到【緩存層】的高可用,是通過緩存數(shù)據(jù)的冗余來實(shí)現(xiàn)的。
緩存層的數(shù)據(jù)冗余又有幾種方式:第一種是利用客戶端的封裝,service對(duì)cache進(jìn)行雙讀或者雙寫。
緩存層也可以通過支持主從同步的緩存集群來解決緩存層的高可用問題。
以redis為例,redis天然支持主從同步,redis官方也有sentinel哨兵機(jī)制,來做redis的存活性檢測(cè)。
自動(dòng)故障轉(zhuǎn)移:當(dāng)redis主掛了的時(shí)候,sentinel能夠探測(cè)到,會(huì)通知調(diào)用方訪問新的redis,整個(gè)過程由sentinel和redis集群配合完成,對(duì)調(diào)用方是透明的。
說完緩存的高可用,這里要多說一句,業(yè)務(wù)對(duì)緩存并不一定有“高可用”要求,更多的對(duì)緩存的使用場(chǎng)景,是用來“加速數(shù)據(jù)訪問”:把一部分?jǐn)?shù)據(jù)放到緩存里,如果緩存掛了或者緩存沒有命中,是可以去后端的數(shù)據(jù)庫(kù)中再取數(shù)據(jù)的。
這類允許“cache miss”的業(yè)務(wù)場(chǎng)景,緩存架構(gòu)的建議是:
將kv緩存封裝成服務(wù)集群,上游設(shè)置一個(gè)代理(代理可以用集群冗余的方式保證高可用),代理的后端根據(jù)緩存訪問的key水平切分成若干個(gè)實(shí)例,每個(gè)實(shí)例的訪問并不做高可用。
緩存實(shí)例掛了屏蔽:當(dāng)有水平切分的實(shí)例掛掉時(shí),代理層直接返回cache miss,此時(shí)緩存掛掉對(duì)調(diào)用方也是透明的。key水平切分實(shí)例減少,不建議做re-hash,這樣容易引發(fā)緩存數(shù)據(jù)的不一致。
【服務(wù)層>數(shù)據(jù)庫(kù)層】的高可用
大部分互聯(lián)網(wǎng)技術(shù),數(shù)據(jù)庫(kù)層都用了“主從同步,讀寫分離”架構(gòu),所以數(shù)據(jù)庫(kù)層的高可用,又分為“讀庫(kù)高可用”與“寫庫(kù)高可用”兩類。
【服務(wù)層>數(shù)據(jù)庫(kù)層“讀”】的高可用
【服務(wù)層】到【數(shù)據(jù)庫(kù)讀】的高可用,是通過讀庫(kù)的冗余來實(shí)現(xiàn)的。
既然冗余了讀庫(kù),一般來說就至少有2個(gè)從庫(kù),“數(shù)據(jù)庫(kù)連接池”會(huì)建立與讀庫(kù)多個(gè)連接,每次請(qǐng)求會(huì)路由到這些讀庫(kù)。
自動(dòng)故障轉(zhuǎn)移:當(dāng)讀庫(kù)掛了的時(shí)候,db-connection-pool能夠探測(cè)到,會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移,將流量自動(dòng)遷移到其他的讀庫(kù),整個(gè)過程由連接池自動(dòng)完成,對(duì)調(diào)用方是透明的(所以說DAO中的數(shù)據(jù)庫(kù)連接池是很重要的基礎(chǔ)組件)。
【服務(wù)層>數(shù)據(jù)庫(kù)層“寫”】的高可用
【服務(wù)層】到【數(shù)據(jù)庫(kù)寫】的高可用,是通過寫庫(kù)的冗余來實(shí)現(xiàn)的。
以mysql為例,可以設(shè)置兩個(gè)mysql雙主同步,一臺(tái)對(duì)線上提供服務(wù),另一臺(tái)冗余以保證高可用,常見的實(shí)踐是keepalived存活探測(cè),相同virtual IP提供服務(wù)。
自動(dòng)故障轉(zhuǎn)移:當(dāng)寫庫(kù)掛了的時(shí)候,keepalived能夠探測(cè)到,會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移,將流量自動(dòng)遷移到shadow-db-master,由于使用的是相同的virtual IP,這個(gè)切換過程對(duì)調(diào)用方是透明的。
五、總結(jié)高可用HA(High Availability)是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一,它通常是指,通過設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間。
方法論上,高可用是通過冗余+自動(dòng)故障轉(zhuǎn)移來實(shí)現(xiàn)的。
整個(gè)互聯(lián)網(wǎng)分層系統(tǒng)架構(gòu)的高可用,又是通過每一層的冗余+自動(dòng)故障轉(zhuǎn)移來綜合實(shí)現(xiàn)的,具體的:
(1)【客戶端層】到【反向代理層】的高可用,是通過反向代理層的冗余實(shí)現(xiàn)的,常見實(shí)踐是keepalived + virtual IP自動(dòng)故障轉(zhuǎn)移
(2)【反向代理層】到【站點(diǎn)層】的高可用,是通過站點(diǎn)層的冗余實(shí)現(xiàn)的,常見實(shí)踐是nginx與web-server之間的存活性探測(cè)與自動(dòng)故障轉(zhuǎn)移
(3)【站點(diǎn)層】到【服務(wù)層】的高可用,是通過服務(wù)層的冗余實(shí)現(xiàn)的,常見實(shí)踐是通過service-connection-pool來保證自動(dòng)故障轉(zhuǎn)移
(4)【服務(wù)層】到【緩存層】的高可用,是通過緩存數(shù)據(jù)的冗余實(shí)現(xiàn)的,常見實(shí)踐是緩存客戶端雙讀雙寫,或者利用緩存集群的主從數(shù)據(jù)同步與sentinel?;钆c自動(dòng)故障轉(zhuǎn)移;更多的業(yè)務(wù)場(chǎng)景,對(duì)緩存沒有高可用要求,可以使用緩存服務(wù)化來對(duì)調(diào)用方屏蔽底層復(fù)雜性
(5)【服務(wù)層】到【數(shù)據(jù)庫(kù)“讀”】的高可用,是通過讀庫(kù)的冗余實(shí)現(xiàn)的,常見實(shí)踐是通過db-connection-pool來保證自動(dòng)故障轉(zhuǎn)移
(6)【服務(wù)層】到【數(shù)據(jù)庫(kù)“寫”】的高可用,是通過寫庫(kù)的冗余實(shí)現(xiàn)的,常見實(shí)踐是keepalived + virtual IP自動(dòng)故障轉(zhuǎn)移
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/61729.html
摘要:是什么基于內(nèi)存有客戶端和服務(wù)器端非關(guān)系型數(shù)據(jù)庫(kù)應(yīng)用場(chǎng)景是什么緩存隊(duì)列數(shù)據(jù)持久存儲(chǔ)如何安裝如何啟動(dòng)如何關(guān)閉客戶端如何啟動(dòng)下載解壓編譯安裝服務(wù)啟動(dòng)注意這種方式啟動(dòng)使用的是默認(rèn)配置通過啟動(dòng)參數(shù)告訴使用指定配置文件使用下面命令啟動(dòng)服務(wù)關(guān) redis 是什么? 基于內(nèi)存 有客戶端和服務(wù)器端 NoSQL非關(guān)系型數(shù)據(jù)庫(kù) redis 應(yīng)用場(chǎng)景是什么? 緩存 隊(duì)列 數(shù)據(jù)持久存儲(chǔ) redis 如何...
閱讀 808·2021-11-17 09:33
閱讀 3856·2021-09-01 10:46
閱讀 1851·2019-08-30 11:02
閱讀 3357·2019-08-29 15:05
閱讀 1456·2019-08-26 11:39
閱讀 2361·2019-08-23 17:04
閱讀 2035·2019-08-23 15:43
閱讀 1427·2019-08-23 14:12