存儲(chǔ)高可用

存儲(chǔ)高可用方案的本質(zhì)都是通過(guò)將數(shù)據(jù)復(fù)制到多個(gè)存儲(chǔ)設(shè)備，通過(guò)數(shù)據(jù)冗余的方式來(lái)實(shí)現(xiàn)高可用，其復(fù)雜性主要體現(xiàn)在如何應(yīng)對(duì)復(fù)制延遲和中斷導(dǎo)致的數(shù)據(jù)不一致問題

• 對(duì)一個(gè)高可用存儲(chǔ)方案，我們需要從以下幾個(gè)方面去進(jìn)行思考和分析：
  • 數(shù)據(jù)如何復(fù)制？
  • 各個(gè)節(jié)點(diǎn)的職責(zé)是什么？
  • 如何應(yīng)對(duì)復(fù)制延遲旁壮？
  • 如何應(yīng)對(duì)復(fù)制中斷？
• 常見的高可用存儲(chǔ)架構(gòu)有主備谐檀、主從抡谐、主主、集群桐猬、分區(qū)麦撵，每一種又可以根據(jù)業(yè)務(wù)的需求進(jìn)行一些特殊的定制化功能，由此衍生出更多的變種

主備復(fù)制

主備復(fù)制是最常見也是最簡(jiǎn)單的一種存儲(chǔ)高可用方案溃肪，幾乎所有的存儲(chǔ)系統(tǒng)都提供了主備復(fù)制的功能免胃，例如 MySQL、Redis乍惊、MongoDB 等

1. 基本實(shí)現(xiàn)

主備方案架構(gòu)圖

• 其整體架構(gòu)比較簡(jiǎn)單杜秸，主備架構(gòu)中的“備機(jī)”主要還是起到一個(gè)備份作用，并不承擔(dān)實(shí)際的業(yè)務(wù)讀寫操作润绎，如果要把備機(jī)改為主機(jī)，需要人工操作

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

• 優(yōu)點(diǎn)：簡(jiǎn)單
  • 對(duì)于客戶端來(lái)說(shuō)诞挨，不需要感知備機(jī)的存在莉撇，即使災(zāi)難恢復(fù)后，原來(lái)的備機(jī)被人工修改為主機(jī)后惶傻，對(duì)于客戶端來(lái)說(shuō)棍郎，只是認(rèn)為主機(jī)的地址換了而已，無(wú)須知道是原來(lái)的備機(jī)升級(jí)為主機(jī)
  • 對(duì)于主機(jī)和備機(jī)來(lái)說(shuō)银室，雙方只需要進(jìn)行數(shù)據(jù)復(fù)制即可涂佃，無(wú)須進(jìn)行狀態(tài)判斷和主備切換這類復(fù)雜的操作
• 主備復(fù)制架構(gòu)的缺點(diǎn)主要有：
  • 備機(jī)僅僅只為備份励翼，并沒有提供讀寫操作，硬件成本上有浪費(fèi)
  • 故障后需要人工干預(yù)辜荠，無(wú)法自動(dòng)恢復(fù)汽抚。人工處理的效率是很低的，可能打電話找到能夠操作的人就耗費(fèi)了 10 分鐘伯病，甚至如果是深更半夜造烁，出了故障都沒人知道。人工在執(zhí)行恢復(fù)操作的過(guò)程中也容易出錯(cuò)午笛，因?yàn)檫@類操作并不常見惭蟋，可能 1 年就 2、3 次药磺，實(shí)際操作的時(shí)候很可能遇到各種意想不到的問題
• 綜合主備復(fù)制架構(gòu)的優(yōu)缺點(diǎn)告组，內(nèi)部的后臺(tái)管理系統(tǒng)使用主備復(fù)制架構(gòu)的情況會(huì)比較多，例如學(xué)生管理系統(tǒng)癌佩、員工管理系統(tǒng)木缝、假期管理系統(tǒng)等，因?yàn)檫@類系統(tǒng)的數(shù)據(jù)變更頻率低驼卖，即使在某些場(chǎng)景下丟失數(shù)據(jù)氨肌，也可以通過(guò)人工的方式補(bǔ)全

主從復(fù)制

主從復(fù)制，主機(jī)負(fù)責(zé)讀寫操作酌畜，從機(jī)只負(fù)責(zé)讀操作怎囚，不負(fù)責(zé)寫操作

1. 基本實(shí)現(xiàn)

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

• 與主備復(fù)制架構(gòu)比較類似，主要的差別點(diǎn)在于從機(jī)正常情況下也是要提供讀的操作

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

• 主從復(fù)制與主備復(fù)制相比桥胞，優(yōu)點(diǎn)有：
  • 主從復(fù)制在主機(jī)故障時(shí)恳守，讀操作相關(guān)的業(yè)務(wù)可以繼續(xù)運(yùn)行
  • 主從復(fù)制架構(gòu)的從機(jī)提供讀操作，發(fā)揮了硬件的性能
• 缺點(diǎn)有：
  • 主從復(fù)制架構(gòu)中贩虾，客戶端需要感知主從關(guān)系催烘，并將不同的操作發(fā)給不同的機(jī)器進(jìn)行處理，復(fù)雜度比主備復(fù)制要高
  • 主從復(fù)制架構(gòu)中缎罢，從機(jī)提供讀業(yè)務(wù)伊群，如果主從復(fù)制延遲比較大，業(yè)務(wù)會(huì)因?yàn)閿?shù)據(jù)不一致出現(xiàn)問題
  • 故障時(shí)需要人工干預(yù)
• 綜合主從復(fù)制的優(yōu)缺點(diǎn)策精，一般情況下舰始，寫少讀多的業(yè)務(wù)使用主從復(fù)制的存儲(chǔ)架構(gòu)比較多。例如咽袜，論壇丸卷、BBS、新聞網(wǎng)站這類業(yè)務(wù)询刹，此類業(yè)務(wù)的讀操作數(shù)量是寫操作數(shù)量的 10 倍甚至 100 倍以上

雙機(jī)切換

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

• 主備復(fù)制和主從復(fù)制方案存在兩個(gè)共性的問題：
  • 主機(jī)故障后谜嫉，無(wú)法進(jìn)行寫操作
  • 如果主機(jī)無(wú)法恢復(fù)萎坷，需要人工指定新的主機(jī)角色
• 雙機(jī)切換就是為了解決這兩個(gè)問題而產(chǎn)生的，包括主備切換和主從切換兩種方案沐兰。簡(jiǎn)單來(lái)說(shuō)哆档，這兩個(gè)方案就是在原有方案的基礎(chǔ)上增加“切換”功能，即系統(tǒng)自動(dòng)決定主機(jī)角色僧鲁，并完成角色切換
• 要實(shí)現(xiàn)一個(gè)完善的切換方案虐呻，必須考慮這幾個(gè)關(guān)鍵的設(shè)計(jì)點(diǎn)：
  • 主備間狀態(tài)判斷
    • 主要包括兩方面：狀態(tài)傳遞的渠道，以及狀態(tài)檢測(cè)的內(nèi)容
    • 狀態(tài)傳遞的渠道：是相互間互相連接寞秃，還是第三方仲裁
    • 狀態(tài)檢測(cè)的內(nèi)容：例如機(jī)器是否掉電斟叼、進(jìn)程是否存在、響應(yīng)是否緩慢等
  • 切換決策
    • 主要包括幾方面：切換時(shí)機(jī)春寿、切換策略朗涩、自動(dòng)程度
    • 切換時(shí)機(jī)：什么情況下備機(jī)應(yīng)該升級(jí)為主機(jī)？是機(jī)器掉電后備機(jī)才升級(jí)绑改，還是主機(jī)上的進(jìn)程不存在就升級(jí)谢床，還是主機(jī)響應(yīng)時(shí)間超過(guò) 2 秒就升級(jí)，還是 3 分鐘內(nèi)主機(jī)連續(xù)重啟 3 次就升級(jí)等
    • 切換策略：原來(lái)的主機(jī)故障恢復(fù)后厘线，要再次切換识腿，確保原來(lái)的主機(jī)繼續(xù)做主機(jī)，還是原來(lái)的主機(jī)故障恢復(fù)后自動(dòng)成為新的備機(jī)
    • 自動(dòng)程度：切換是完全自動(dòng)的造壮，還是半自動(dòng)的渡讼？例如，系統(tǒng)判斷當(dāng)前需要切換耳璧，但需要人工做最終的確認(rèn)操作（例如成箫，單擊一下“切換”按鈕）
  • 數(shù)據(jù)沖突解決
    • 當(dāng)原有故障的主機(jī)恢復(fù)后，新舊主機(jī)之間可能存在數(shù)據(jù)沖突
    • 例如旨枯，用戶在舊主機(jī)上新增了一條 ID 為 100 的數(shù)據(jù)蹬昌，這個(gè)數(shù)據(jù)還沒有復(fù)制到舊的備機(jī)，此時(shí)發(fā)生了切換攀隔，舊的備機(jī)升級(jí)為新的主機(jī)皂贩，用戶又在新的主機(jī)上新增了一條 ID 為 100 的數(shù)據(jù)，當(dāng)舊的故障主機(jī)恢復(fù)后昆汹，這兩條 ID 都為 100 的數(shù)據(jù)先紫，應(yīng)該怎么處理
    • 以上設(shè)計(jì)點(diǎn)并沒有統(tǒng)一的答案，不同的業(yè)務(wù)要求不一樣筹煮，所以切換方案比復(fù)制方案不只是多了一個(gè)切換功能那么簡(jiǎn)單，而是復(fù)雜度上升了一個(gè)量級(jí)
    • 如果復(fù)制方案的代碼是 1000 行居夹，那么切換方案的代碼可能就是 10000 行败潦，多出來(lái)的那 9000 行就是用于實(shí)現(xiàn)上面所講的 3 個(gè)設(shè)計(jì)點(diǎn)的

2. 常見架構(gòu)
   根據(jù)狀態(tài)傳遞渠道的不同本冲，常見的主備切換架構(gòu)有三種形式：互連式、中介式和模擬式

互連式

故名思議劫扒，互連式就是指主備機(jī)直接建立狀態(tài)傳遞的渠道檬洞，架構(gòu)圖請(qǐng)注意與主備復(fù)制架構(gòu)對(duì)比

互聯(lián)式架構(gòu)圖

• 在主備復(fù)制的架構(gòu)基礎(chǔ)上，主機(jī)和備機(jī)多了一個(gè)“狀態(tài)傳遞”的通道沟饥，這個(gè)通道就是用來(lái)傳遞狀態(tài)信息的添怔。這個(gè)通道的具體實(shí)現(xiàn)可以有很多方式：
  • 可以是網(wǎng)絡(luò)連接（例如，各開一個(gè)端口）贤旷，也可以是非網(wǎng)絡(luò)連接（用串口線連接）广料。
  • 可以是主機(jī)發(fā)送狀態(tài)給備機(jī)，也可以是備機(jī)到主機(jī)來(lái)獲取狀態(tài)信息幼驶。
  • 可以和數(shù)據(jù)復(fù)制通道共用艾杏，也可以獨(dú)立一條通道。
  • 狀態(tài)傳遞通道可以是一條盅藻，也可以是多條购桑，還可以是不同類型的通道混合（例如，網(wǎng)絡(luò) + 串口）
• 為了充分利用切換方案能夠自動(dòng)決定主機(jī)這個(gè)優(yōu)勢(shì)氏淑，客戶端這里也會(huì)有一些相應(yīng)的改變勃蜘，常見的方式有：
  • 為了切換后不影響客戶端的訪問，主機(jī)和備機(jī)之間共享一個(gè)對(duì)客戶端來(lái)說(shuō)唯一的地址假残。例如虛擬 IP缭贡，主機(jī)需要綁定這個(gè)虛擬的 IP。
  • 客戶端同時(shí)記錄主備機(jī)的地址守问，哪個(gè)能訪問就訪問哪個(gè)匀归；備機(jī)雖然能收到客戶端的操作請(qǐng)求，但是會(huì)直接拒絕耗帕，拒絕的原因就是“備機(jī)不對(duì)外提供服務(wù)”
• 互連式主備切換主要的缺點(diǎn)在于：
  • 如果狀態(tài)傳遞的通道本身有故障（例如穆端，網(wǎng)線被人不小心踢掉了），那么備機(jī)也會(huì)認(rèn)為主機(jī)故障了從而將自己升級(jí)為主機(jī)仿便，而此時(shí)主機(jī)并沒有故障体啰，最終就可能出現(xiàn)兩個(gè)主機(jī)。
  • 雖然可以通過(guò)增加多個(gè)通道來(lái)增強(qiáng)狀態(tài)傳遞的可靠性嗽仪，但這樣做只是降低了通道故障概率而已荒勇，不能從根本上解決這個(gè)缺點(diǎn)，而且通道越多闻坚，后續(xù)的狀態(tài)決策會(huì)更加復(fù)雜沽翔，因?yàn)閷?duì)備機(jī)來(lái)說(shuō)，可能從不同的通道收到了不同甚至矛盾的狀態(tài)信息

中介式

中介式指的是在主備兩者之外引入第三方中介，主備機(jī)之間不直接連接仅偎，而都去連接中介跨蟹，并且通過(guò)中介來(lái)傳遞狀態(tài)信息，其架構(gòu)圖如下：

中介式互聯(lián)架構(gòu)圖

• 對(duì)比一下互連式切換架構(gòu)橘沥，我們可以看到窗轩，主機(jī)和備機(jī)不再通過(guò)互聯(lián)通道傳遞狀態(tài)信息，而是都將狀態(tài)上報(bào)給中介這一角色座咆。
  • 單純從架構(gòu)上看痢艺，中介式似乎比互連式更加復(fù)雜了，首先要引入中介介陶，然后要各自上報(bào)狀態(tài)
  • 然而事實(shí)上堤舒，中介式架構(gòu)在狀態(tài)傳遞和決策上卻更加簡(jiǎn)單了
  • 連接管理更簡(jiǎn)單：主備機(jī)無(wú)須再建立和管理多種類型的狀態(tài)傳遞連接通道，只要連接到中介即可斤蔓，實(shí)際上是降低了主備機(jī)的連接管理復(fù)雜度
  • 狀態(tài)決策更簡(jiǎn)單：主備機(jī)的狀態(tài)決策簡(jiǎn)單了植酥，無(wú)須考慮多種類型的連接通道獲取的狀態(tài)信息如何決策的問題，只需要按照下面簡(jiǎn)單的算法即可完成狀態(tài)決策
    • 無(wú)論是主機(jī)還是備機(jī)弦牡，初始狀態(tài)都是備機(jī)友驮，并且只要與中介斷開連接，就將自己降級(jí)為備機(jī)驾锰，因此可能出現(xiàn)雙備機(jī)的情況卸留。
    • 主機(jī)與中介斷連后，中介能夠立刻告知備機(jī)椭豫，備機(jī)將自己升級(jí)為主機(jī)耻瑟。
    • 如果是網(wǎng)絡(luò)中斷導(dǎo)致主機(jī)與中介斷連，主機(jī)自己會(huì)降級(jí)為備機(jī)赏酥，網(wǎng)絡(luò)恢復(fù)后喳整，舊的主機(jī)以新的備機(jī)身份向中介上報(bào)自己的狀態(tài)。
    • 如果是掉電重啟或者進(jìn)程重啟裸扶，舊的主機(jī)初始狀態(tài)為備機(jī)框都，與中介恢復(fù)連接后，發(fā)現(xiàn)已經(jīng)有主機(jī)了呵晨，保持自己備機(jī)狀態(tài)不變魏保。
    • 主備機(jī)與中介連接都正常的情況下，按照實(shí)際的狀態(tài)決定是否進(jìn)行切換摸屠。例如谓罗，主機(jī)響應(yīng)時(shí)間超過(guò) 3 秒就進(jìn)行切換，主機(jī)降級(jí)為備機(jī)季二，備機(jī)升級(jí)為主機(jī)即可檩咱。
• 雖然中介式架構(gòu)在狀態(tài)傳遞和狀態(tài)決策上更加簡(jiǎn)單，但并不意味著這種優(yōu)點(diǎn)是沒有代價(jià)的，其關(guān)鍵代價(jià)就在于如何實(shí)現(xiàn)中介本身的高可用税手。如果中介自己宕機(jī)了蜂筹，整個(gè)系統(tǒng)就進(jìn)入了雙備的狀態(tài)，寫操作相關(guān)的業(yè)務(wù)就不可用了芦倒。這就陷入了一個(gè)遞歸的陷阱：為了實(shí)現(xiàn)高可用，我們引入中介不翩，但中介本身又要求高可用兵扬，于是又要設(shè)計(jì)中介的高可用方案……如此遞歸下去就無(wú)窮無(wú)盡了
• 開源方案已經(jīng)有比較成熟的中介式解決方案紫谷，例如 ZooKeeper 和 Keepalived胰坟。ZooKeeper 本身已經(jīng)實(shí)現(xiàn)了高可用集群架構(gòu)笑陈，因此已經(jīng)幫我們解決了中介本身的可靠性問題先改，在工程實(shí)踐中推薦基于 ZooKeeper 搭建中介式切換架構(gòu)

模擬式

模擬式指主備機(jī)之間并不傳遞任何狀態(tài)數(shù)據(jù)蜂厅，而是備機(jī)模擬成一個(gè)客戶端蝇摸，向主機(jī)發(fā)起模擬的讀寫操作宿刮，根據(jù)讀寫操作的響應(yīng)情況來(lái)判斷主機(jī)的狀態(tài)是辕。其基本架構(gòu)如下：

模擬式互聯(lián)架構(gòu)圖

• 對(duì)比一下互連式切換架構(gòu)眉反，我們可以看到昙啄，主備機(jī)之間只有數(shù)據(jù)復(fù)制通道，而沒有狀態(tài)傳遞通道寸五，備機(jī)通過(guò)模擬的讀寫操作來(lái)探測(cè)主機(jī)的狀態(tài)梳凛，然后根據(jù)讀寫操作的響應(yīng)情況來(lái)進(jìn)行狀態(tài)決策
• 模擬式切換與互連式切換相比，優(yōu)點(diǎn)是實(shí)現(xiàn)更加簡(jiǎn)單梳杏，因?yàn)槭∪チ藸顟B(tài)傳遞通道的建立和管理工作
• 因?yàn)槟M式讀寫操作獲取的狀態(tài)信息只有響應(yīng)信息（例如韧拒，HTTP 404，超時(shí)十性、響應(yīng)時(shí)間超過(guò) 3 秒等）叛溢，沒有互連式那樣多樣（除了響應(yīng)信息，還可以包含 CPU 負(fù)載劲适、I/O 負(fù)載楷掉、吞吐量、響應(yīng)時(shí)間等）减响，基于有限的狀態(tài)來(lái)做狀態(tài)決策靖诗，可能出現(xiàn)偏差

主主復(fù)制

主主復(fù)制指的是兩臺(tái)機(jī)器都是主機(jī)，互相將數(shù)據(jù)復(fù)制給對(duì)方支示，客戶端可以任意挑選其中一臺(tái)機(jī)器進(jìn)行讀寫操作

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

• 相比主備切換架構(gòu)刊橘，主主復(fù)制架構(gòu)具有如下特點(diǎn)：
  • 兩臺(tái)都是主機(jī)，不存在切換的概念
  • 客戶端無(wú)須區(qū)分不同角色的主機(jī)颂鸿，隨便將讀寫操作發(fā)送給哪臺(tái)主機(jī)都可以
• 從上面的描述來(lái)看促绵，主主復(fù)制架構(gòu)從總體上來(lái)看要簡(jiǎn)單很多，無(wú)須狀態(tài)信息傳遞，也無(wú)須狀態(tài)決策和狀態(tài)切換败晴。然而事實(shí)上主主復(fù)制架構(gòu)也并不簡(jiǎn)單浓冒，而是有其獨(dú)特的復(fù)雜性，具體表現(xiàn)在：如果采取主主復(fù)制架構(gòu)尖坤，必須保證數(shù)據(jù)能夠雙向復(fù)制稳懒，而很多數(shù)據(jù)是不能雙向復(fù)制的。例如：
  • 用戶注冊(cè)后生成的用戶 ID慢味，如果按照數(shù)字增長(zhǎng)场梆，那就不能雙向復(fù)制，否則就會(huì)出現(xiàn) X 用戶在主機(jī) A 注冊(cè)纯路，分配的用戶 ID 是 100或油，同時(shí) Y 用戶在主機(jī) B 注冊(cè)，分配的用戶 ID 也是 100驰唬，這就出現(xiàn)了沖突顶岸。
  • 庫(kù)存不能雙向復(fù)制。例如叫编，一件商品庫(kù)存 100 件辖佣，主機(jī) A 上減了 1 件變成 99，主機(jī) B 上減了 2 件變成 98宵溅，然后主機(jī) A 將庫(kù)存 99 復(fù)制到主機(jī) B凌简，主機(jī) B 原有的庫(kù)存 98 被覆蓋，變成了 99恃逻，而實(shí)際上此時(shí)真正的庫(kù)存是 97雏搂。類似的還有余額數(shù)據(jù)。
• 主主復(fù)制架構(gòu)對(duì)數(shù)據(jù)的設(shè)計(jì)有嚴(yán)格的要求寇损，一般適合于那些臨時(shí)性凸郑、可丟失、可覆蓋的數(shù)據(jù)場(chǎng)景矛市。例如芙沥，用戶登錄產(chǎn)生的 session 數(shù)據(jù)（可以重新登錄生成）、用戶行為的日志數(shù)據(jù)（可以丟失）浊吏、論壇的草稿數(shù)據(jù)（可以丟失）等

小結(jié)

本文講了高可用存儲(chǔ)架構(gòu)中常見的雙機(jī)架構(gòu)而昨，分析了每類架構(gòu)的優(yōu)缺點(diǎn)以及適應(yīng)場(chǎng)景，希望對(duì)你有所幫助