高可用存儲架構(gòu):雙機(jī)架構(gòu)

——————————————————摘抄自《極客時間 李運(yùn)華 從0開始學(xué)架構(gòu)》
存儲高可用方案的本質(zhì)都是通過將數(shù)據(jù)復(fù)制到多個存儲設(shè)備,通過數(shù)據(jù)冗余的方式來實現(xiàn)高可用错览,其復(fù)雜性主要體現(xiàn)在如何應(yīng)對復(fù)制延遲和中斷導(dǎo)致的數(shù)據(jù)不一致問題。因此吆录,對任何一個高可用存儲方案厘肮,我們需要從以下幾個方面去進(jìn)行思考和分析:

  • 數(shù)據(jù)如何復(fù)制拷橘?

  • 各個節(jié)點的職責(zé)是什么毅弧?

  • 如何應(yīng)對復(fù)制延遲气嫁?

  • 如何應(yīng)對復(fù)制中斷?

常見的高可用存儲架構(gòu)有主備够坐、主從寸宵、主主、集群元咙、分區(qū)梯影,每一種又可以根據(jù)業(yè)務(wù)的需求進(jìn)行一些特殊的定制化功能,由此衍生出更多的變種庶香。由于不同業(yè)務(wù)的定制功能難以通用化甲棍,今天我將針對業(yè)界通用的方案,來分析常見的雙機(jī)高可用架構(gòu):主備脉课、主從救军、主備 / 主從切換和主主。

主備復(fù)制

主備復(fù)制是最常見也是最簡單的一種存儲高可用方案倘零,幾乎所有的存儲系統(tǒng)都提供了主備復(fù)制的功能唱遭,例如 MySQL、Redis呈驶、MongoDB 等拷泽。

1. 基本實現(xiàn)

下面是標(biāo)準(zhǔn)的主備方案結(jié)構(gòu)圖:

主備方案結(jié)構(gòu)圖

其整體架構(gòu)比較簡單,主備架構(gòu)中的“備機(jī)”主要還是起到一個備份作用袖瞻,并不承擔(dān)實際的業(yè)務(wù)讀寫操作司致,如果要把備機(jī)改為主機(jī),需要人工操作聋迎。

2. 優(yōu)缺點分析

主備復(fù)制架構(gòu)的優(yōu)點就是簡單脂矫,表現(xiàn)有:

  • 對于客戶端來說,不需要感知備機(jī)的存在霉晕。

  • 對于主機(jī)和備機(jī)來說庭再,雙方只需要進(jìn)行數(shù)據(jù)復(fù)制即可,無須進(jìn)行狀態(tài)判斷和主備切換這類復(fù)雜的操作牺堰。

主備復(fù)制架構(gòu)的缺點主要有:

  • 備機(jī)僅僅只為備份拄轻,并沒有提供讀寫操作,硬件成本上有浪費伟葫。

  • 故障后需要人工干預(yù)恨搓,無法自動恢復(fù)。
    綜合主備復(fù)制架構(gòu)的優(yōu)缺點,內(nèi)部的后臺管理系統(tǒng)使用主備復(fù)制架構(gòu)的情況會比較多斧抱。

主從復(fù)制

主機(jī)負(fù)責(zé)讀寫操作常拓,從機(jī)只負(fù)責(zé)讀操作,不負(fù)責(zé)寫操作夺姑。

1. 基本實現(xiàn)

下面是標(biāo)準(zhǔn)的主從復(fù)制架構(gòu):

主從復(fù)制架構(gòu)

與主備復(fù)制架構(gòu)比較類似墩邀,主要的差別點在于從機(jī)正常情況下也是要提供讀的操作掌猛。

2. 優(yōu)缺點分析

主從復(fù)制與主備復(fù)制相比盏浙,優(yōu)點有:

  • 主從復(fù)制在主機(jī)故障時,讀操作相關(guān)的業(yè)務(wù)可以繼續(xù)運(yùn)行荔茬。

  • 主從復(fù)制架構(gòu)的從機(jī)提供讀操作废膘,發(fā)揮了硬件的性能。

缺點有:

  • 主從復(fù)制架構(gòu)中慕蔚,客戶端需要感知主從關(guān)系丐黄,并將不同的操作發(fā)給不同的機(jī)器進(jìn)行處理,復(fù)雜度比主備復(fù)制要高孔飒。

  • 主從復(fù)制架構(gòu)中灌闺,從機(jī)提供讀業(yè)務(wù),如果主從復(fù)制延遲比較大坏瞄,業(yè)務(wù)會因為數(shù)據(jù)不一致出現(xiàn)問題桂对。

  • 故障時需要人工干預(yù)。

綜合主從復(fù)制的優(yōu)缺點鸠匀,一般情況下蕉斜,寫少讀多的業(yè)務(wù)使用主從復(fù)制的存儲架構(gòu)比較多。缀棍。

雙機(jī)切換

1. 設(shè)計關(guān)鍵

主備復(fù)制和主從復(fù)制方案存在兩個共性的問題:

  • 主機(jī)故障后宅此,無法進(jìn)行寫操作。

  • 如果主機(jī)無法恢復(fù)爬范,需要人工指定新的主機(jī)角色父腕。

雙機(jī)切換就是為了解決這兩個問題而產(chǎn)生的,包括主備切換和主從切換兩種方案青瀑。簡單來說璧亮,這兩個方案就是在原有方案的基礎(chǔ)上增加“切換”功能,即系統(tǒng)自動決定主機(jī)角色狱窘,并完成角色切換杜顺。由于主備切換和主從切換在切換的設(shè)計上沒有差別,我接下來以主備切換為例蘸炸,一起來看看雙機(jī)切換架構(gòu)是如何實現(xiàn)的躬络。

要實現(xiàn)一個完善的切換方案,必須考慮這幾個關(guān)鍵的設(shè)計點:

  • 主備間狀態(tài)判斷

主要包括兩方面:狀態(tài)傳遞的渠道搭儒,以及狀態(tài)檢測的內(nèi)容穷当。

狀態(tài)傳遞的渠道:是相互間互相連接提茁,還是第三方仲裁?

狀態(tài)檢測的內(nèi)容:例如機(jī)器是否掉電馁菜、進(jìn)程是否存在茴扁、響應(yīng)是否緩慢等。

  • 切換決策

主要包括幾方面:切換時機(jī)汪疮、切換策略峭火、自動程度。

  • 數(shù)據(jù)沖突解決

2. 常見架構(gòu)

根據(jù)狀態(tài)傳遞渠道的不同智嚷,常見的主備切換架構(gòu)有三種形式:互連式卖丸、中介式和模擬式。

互連式

故名思議盏道,互連式就是指主備機(jī)直接建立狀態(tài)傳遞的渠道稍浆,架構(gòu)圖請注意與主備復(fù)制架構(gòu)對比。

互連式

你可以看到猜嘱,在主備復(fù)制的架構(gòu)基礎(chǔ)上衅枫,主機(jī)和備機(jī)多了一個“狀態(tài)傳遞”的通道,這個通道就是用來傳遞狀態(tài)信息的朗伶。這個通道的具體實現(xiàn)可以有很多方式:

  • 可以是網(wǎng)絡(luò)連接(例如弦撩,各開一個端口),也可以是非網(wǎng)絡(luò)連接(用串口線連接)腕让。

  • 可以是主機(jī)發(fā)送狀態(tài)給備機(jī)孤钦,也可以是備機(jī)到主機(jī)來獲取狀態(tài)信息。

  • 可以和數(shù)據(jù)復(fù)制通道共用纯丸,也可以獨立一條通道偏形。

  • 狀態(tài)傳遞通道可以是一條,也可以是多條觉鼻,還可以是不同類型的通道混合(例如俊扭,網(wǎng)絡(luò) + 串口)。

為了充分利用切換方案能夠自動決定主機(jī)這個優(yōu)勢坠陈,客戶端這里也會有一些相應(yīng)的改變萨惑,常見的方式有:

  • 為了切換后不影響客戶端的訪問,主機(jī)和備機(jī)之間共享一個對客戶端來說唯一的地址仇矾。例如虛擬 IP庸蔼,主機(jī)需要綁定這個虛擬的 IP。

  • 客戶端同時記錄主備機(jī)的地址贮匕,哪個能訪問就訪問哪個姐仅;備機(jī)雖然能收到客戶端的操作請求,但是會直接拒絕,拒絕的原因就是“備機(jī)不對外提供服務(wù)”掏膏。

互連式主備切換主要的缺點在于:

  • 如果狀態(tài)傳遞的通道本身有故障(例如劳翰,網(wǎng)線被人不小心踢掉了),那么備機(jī)也會認(rèn)為主機(jī)故障了從而將自己升級為主機(jī),而此時主機(jī)并沒有故障,最終就可能出現(xiàn)兩個主機(jī)肆捕。

  • 雖然可以通過增加多個通道來增強(qiáng)狀態(tài)傳遞的可靠性,但這樣做只是降低了通道故障概率而已生均,不能從根本上解決這個缺點,而且通道越多悼做,后續(xù)的狀態(tài)決策會更加復(fù)雜疯特,因為對備機(jī)來說,可能從不同的通道收到了不同甚至矛盾的狀態(tài)信息肛走。

中介式

中介式指的是在主備兩者之外引入第三方中介,主備機(jī)之間不直接連接录别,而都去連接中介朽色,并且通過中介來傳遞狀態(tài)信息,其架構(gòu)圖如下:

中介式

對比一下互連式切換架構(gòu)组题,我們可以看到葫男,主機(jī)和備機(jī)不再通過互聯(lián)通道傳遞狀態(tài)信息,而是都將狀態(tài)上報給中介這一角色崔列。單純從架構(gòu)上看梢褐,中介式似乎比互連式更加復(fù)雜了,首先要引入中介赵讯,然后要各自上報狀態(tài)盈咳。然而事實上,中介式架構(gòu)在狀態(tài)傳遞和決策上卻更加簡單了边翼,這是為何呢鱼响?

連接管理更簡單:主備機(jī)無須再建立和管理多種類型的狀態(tài)傳遞連接通道,只要連接到中介即可组底,實際上是降低了主備機(jī)的連接管理復(fù)雜度丈积。

狀態(tài)決策更簡單:主備機(jī)的狀態(tài)決策簡單了,無須考慮多種類型的連接通道獲取的狀態(tài)信息如何決策的問題债鸡,只需要按照下面簡單的算法即可完成狀態(tài)決策江滨。

  • 無論是主機(jī)還是備機(jī),初始狀態(tài)都是備機(jī)厌均,并且只要與中介斷開連接唬滑,就將自己降級為備機(jī),因此可能出現(xiàn)雙備機(jī)的情況。

  • 主機(jī)與中介斷連后间雀,中介能夠立刻告知備機(jī)悔详,備機(jī)將自己升級為主機(jī)。

  • 如果是網(wǎng)絡(luò)中斷導(dǎo)致主機(jī)與中介斷連惹挟,主機(jī)自己會降級為備機(jī)茄螃,網(wǎng)絡(luò)恢復(fù)后,舊的主機(jī)以新的備機(jī)身份向中介上報自己的狀態(tài)连锯。

  • 如果是掉電重啟或者進(jìn)程重啟归苍,舊的主機(jī)初始狀態(tài)為備機(jī),與中介恢復(fù)連接后运怖,發(fā)現(xiàn)已經(jīng)有主機(jī)了拼弃,保持自己備機(jī)狀態(tài)不變。

  • 主備機(jī)與中介連接都正常的情況下摇展,按照實際的狀態(tài)決定是否進(jìn)行切換吻氧。例如,主機(jī)響應(yīng)時間超過 3 秒就進(jìn)行切換咏连,主機(jī)降級為備機(jī)盯孙,備機(jī)升級為主機(jī)即可。

雖然中介式架構(gòu)在狀態(tài)傳遞和狀態(tài)決策上更加簡單祟滴,但并不意味著這種優(yōu)點是沒有代價的振惰,其關(guān)鍵代價就在于如何實現(xiàn)中介本身的高可用。如果中介自己宕機(jī)了垄懂,整個系統(tǒng)就進(jìn)入了雙備的狀態(tài)骑晶,寫操作相關(guān)的業(yè)務(wù)就不可用了。這就陷入了一個遞歸的陷阱:為了實現(xiàn)高可用草慧,我們引入中介桶蛔,但中介本身又要求高可用,于是又要設(shè)計中介的高可用方案……如此遞歸下去就無窮無盡了冠蒋。

幸運(yùn)的是羽圃,開源方案已經(jīng)有比較成熟的中介式解決方案,例如 ZooKeeper 和 Keepalived抖剿。ZooKeeper 本身已經(jīng)實現(xiàn)了高可用集群架構(gòu)朽寞,因此已經(jīng)幫我們解決了中介本身的可靠性問題,在工程實踐中推薦基于 ZooKeeper 搭建中介式切換架構(gòu)斩郎。

模擬式

模擬式指主備機(jī)之間并不傳遞任何狀態(tài)數(shù)據(jù)脑融,而是備機(jī)模擬成一個客戶端,向主機(jī)發(fā)起模擬的讀寫操作缩宜,根據(jù)讀寫操作的響應(yīng)情況來判斷主機(jī)的狀態(tài)肘迎。其基本架構(gòu)如下:

模擬式

對比一下互連式切換架構(gòu)甥温,我們可以看到,主備機(jī)之間只有數(shù)據(jù)復(fù)制通道妓布,而沒有狀態(tài)傳遞通道姻蚓,備機(jī)通過模擬的讀寫操作來探測主機(jī)的狀態(tài),然后根據(jù)讀寫操作的響應(yīng)情況來進(jìn)行狀態(tài)決策匣沼。

模擬式切換與互連式切換相比狰挡,優(yōu)點是實現(xiàn)更加簡單,因為省去了狀態(tài)傳遞通道的建立和管理工作释涛。

簡單既是優(yōu)點加叁,同時也是缺點。因為模擬式讀寫操作獲取的狀態(tài)信息只有響應(yīng)信息(例如唇撬,HTTP 404它匕,超時、響應(yīng)時間超過 3 秒等)窖认,沒有互連式那樣多樣(除了響應(yīng)信息豫柬,還可以包含 CPU 負(fù)載、I/O 負(fù)載耀态、吞吐量轮傍、響應(yīng)時間等),基于有限的狀態(tài)來做狀態(tài)決策首装,可能出現(xiàn)偏差。

主主復(fù)制

主主復(fù)制指的是兩臺機(jī)器都是主機(jī)杭跪,互相將數(shù)據(jù)復(fù)制給對方仙逻,客戶端可以任意挑選其中一臺機(jī)器進(jìn)行讀寫操作,下面是基本架構(gòu)圖涧尿。

image.png

相比主備切換架構(gòu)系奉,主主復(fù)制架構(gòu)具有如下特點:

  • 兩臺都是主機(jī),不存在切換的概念姑廉。

  • 客戶端無須區(qū)分不同角色的主機(jī)缺亮,隨便將讀寫操作發(fā)送給哪臺主機(jī)都可以。

從上面的描述來看桥言,主主復(fù)制架構(gòu)從總體上來看要簡單很多萌踱,無須狀態(tài)信息傳遞,也無須狀態(tài)決策和狀態(tài)切換号阿。然而事實上主主復(fù)制架構(gòu)也并不簡單并鸵,而是有其獨特的復(fù)雜性,具體表現(xiàn)在:如果采取主主復(fù)制架構(gòu)扔涧,必須保證數(shù)據(jù)能夠雙向復(fù)制园担,而很多數(shù)據(jù)是不能雙向復(fù)制的届谈。
因此,主主復(fù)制架構(gòu)對數(shù)據(jù)的設(shè)計有嚴(yán)格的要求弯汰,一般適合于那些臨時性艰山、可丟失、可覆蓋的數(shù)據(jù)場景咏闪。例如曙搬,用戶登錄產(chǎn)生的 session 數(shù)據(jù)(可以重新登錄生成)、用戶行為的日志數(shù)據(jù)(可以丟失)汤踏、論壇的草稿數(shù)據(jù)(可以丟失)等织鲸。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市溪胶,隨后出現(xiàn)的幾起案子搂擦,更是在濱河造成了極大的恐慌,老刑警劉巖哗脖,帶你破解...
    沈念sama閱讀 211,348評論 6 491
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件瀑踢,死亡現(xiàn)場離奇詭異,居然都是意外死亡才避,警方通過查閱死者的電腦和手機(jī)橱夭,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,122評論 2 385
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來桑逝,“玉大人棘劣,你說我怎么就攤上這事±愣簦” “怎么了茬暇?”我有些...
    開封第一講書人閱讀 156,936評論 0 347
  • 文/不壞的土叔 我叫張陵,是天一觀的道長寡喝。 經(jīng)常有香客問我糙俗,道長,這世上最難降的妖魔是什么预鬓? 我笑而不...
    開封第一講書人閱讀 56,427評論 1 283
  • 正文 為了忘掉前任巧骚,我火速辦了婚禮,結(jié)果婚禮上格二,老公的妹妹穿的比我還像新娘劈彪。我一直安慰自己,他們只是感情好蟋定,可當(dāng)我...
    茶點故事閱讀 65,467評論 6 385
  • 文/花漫 我一把揭開白布粉臊。 她就那樣靜靜地躺著,像睡著了一般驶兜。 火紅的嫁衣襯著肌膚如雪扼仲。 梳的紋絲不亂的頭發(fā)上远寸,一...
    開封第一講書人閱讀 49,785評論 1 290
  • 那天,我揣著相機(jī)與錄音屠凶,去河邊找鬼驰后。 笑死,一個胖子當(dāng)著我的面吹牛矗愧,可吹牛的內(nèi)容都是我干的灶芝。 我是一名探鬼主播,決...
    沈念sama閱讀 38,931評論 3 406
  • 文/蒼蘭香墨 我猛地睜開眼唉韭,長吁一口氣:“原來是場噩夢啊……” “哼夜涕!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起属愤,我...
    開封第一講書人閱讀 37,696評論 0 266
  • 序言:老撾萬榮一對情侶失蹤女器,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后住诸,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體驾胆,經(jīng)...
    沈念sama閱讀 44,141評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,483評論 2 327
  • 正文 我和宋清朗相戀三年贱呐,在試婚紗的時候發(fā)現(xiàn)自己被綠了丧诺。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,625評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡奄薇,死狀恐怖驳阎,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情馁蒂,我是刑警寧澤搞隐,帶...
    沈念sama閱讀 34,291評論 4 329
  • 正文 年R本政府宣布,位于F島的核電站远搪,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏逢捺。R本人自食惡果不足惜谁鳍,卻給世界環(huán)境...
    茶點故事閱讀 39,892評論 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望劫瞳。 院中可真熱鬧倘潜,春花似錦、人聲如沸志于。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,741評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽伺绽。三九已至养泡,卻和暖如春嗜湃,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背澜掩。 一陣腳步聲響...
    開封第一講書人閱讀 31,977評論 1 265
  • 我被黑心中介騙來泰國打工购披, 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人肩榕。 一個月前我還...
    沈念sama閱讀 46,324評論 2 360
  • 正文 我出身青樓刚陡,卻偏偏與公主長得像,于是被迫代替她去往敵國和親株汉。 傳聞我的和親對象是個殘疾皇子筐乳,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,492評論 2 348

推薦閱讀更多精彩內(nèi)容