對任何一個高可用存儲方案底洗，我們需要從以下幾個方面去進行思考和分析：

數(shù)據(jù)如何復制盆耽？

各個節(jié)點的職責是什么莹桅？

如何應(yīng)對復制延遲？

如何應(yīng)對復制中斷尼荆？

常見的高可用存儲架構(gòu)有主備左腔、主從、主主捅儒、集群液样、分區(qū)，每一種又可以根據(jù)業(yè)務(wù)的需求進行一些特殊的定制化功能巧还，由此衍生出更多的變種鞭莽。由于不同業(yè)務(wù)的定制功能難以通用化，今天我將針對業(yè)界通用的方案麸祷，來分析常見的雙機高可用架構(gòu)：主備澎怒、主從、主備 / 主從切換和主主摇锋。

一丹拯、主備復制

主備復制是最常見也是最簡單的一種存儲高可用方案，幾乎所有的存儲系統(tǒng)都提供了主備復制的功能荸恕，例如 MySQL、Redis死相、MongoDB 等融求。

1. 基本實現(xiàn)

下面是標準的主備方案結(jié)構(gòu)圖：

其整體架構(gòu)比較簡單，主備架構(gòu)中的“備機”主要還是起到一個備份作用算撮，并不承擔實際的業(yè)務(wù)讀寫操作生宛，如果要把備機改為主機，需要人工操作肮柜。

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

優(yōu)點就是簡單陷舅，表現(xiàn)有：

對于客戶端來說，不需要感知備機的存在审洞，即使災(zāi)難恢復后莱睁，原來的備機被人工修改為主機后，對于客戶端來說芒澜，只是認為主機的地址換了而已仰剿，無須知道是原來的備機升級為主機。

對于主機和備機來說痴晦，雙方只需要進行數(shù)據(jù)復制即可南吮，無須進行狀態(tài)判斷和主備切換這類復雜的操作。

缺點主要有：

備機僅僅只為備份誊酌，并沒有提供讀寫操作部凑，硬件成本上有浪費露乏。

故障后需要人工干預(yù)，無法自動恢復涂邀。人工處理的效率是很低的施无，可能打電話找到能夠操作的人就耗費了 10 分鐘，甚至如果是深更半夜必孤，出了故障都沒人知道猾骡。人工在執(zhí)行恢復操作的過程中也容易出錯，因為這類操作并不常見敷搪，可能 1 年就 2兴想、3 次，實際操作的時候很可能遇到各種意想不到的問題赡勘。

綜合主備復制架構(gòu)的優(yōu)缺點嫂便，內(nèi)部的后臺管理系統(tǒng)使用主備復制架構(gòu)的情況會比較多，例如學生管理系統(tǒng)闸与、員工管理系統(tǒng)毙替、假期管理系統(tǒng)等，因為這類系統(tǒng)的數(shù)據(jù)變更頻率低践樱，即使在某些場景下丟失數(shù)據(jù)厂画，也可以通過人工的方式補全。

二拷邢、主從復制

主從復制和主備復制只有一字之差袱院，“從”意思是“隨從、仆從”瞭稼，“備”的意思是備份忽洛。我們可以理解為仆從是要幫主人干活的，這里的干活就是承擔“讀”的操作环肘。也就是說欲虚，主機負責讀寫操作，從機只負責讀操作悔雹，不負責寫操作复哆。

1. 基本實現(xiàn)

下面是標準的主從復制架構(gòu)：

與主備復制架構(gòu)比較類似，主要的差別點在于從機正常情況下也是要提供讀的操作荠商。

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

主從復制與主備復制相比寂恬，優(yōu)點有：

主從復制在主機故障時，讀操作相關(guān)的業(yè)務(wù)可以繼續(xù)運行莱没。

主從復制架構(gòu)的從機提供讀操作初肉，發(fā)揮了硬件的性能。

缺點有：

主從復制架構(gòu)中饰躲，客戶端需要感知主從關(guān)系牙咏，并將不同的操作發(fā)給不同的機器進行處理臼隔，復雜度比主備復制要高。

主從復制架構(gòu)中妄壶，從機提供讀業(yè)務(wù)摔握，如果主從復制延遲比較大，業(yè)務(wù)會因為數(shù)據(jù)不一致出現(xiàn)問題丁寄。

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

綜合主從復制的優(yōu)缺點俺陋，一般情況下贞滨，寫少讀多的業(yè)務(wù)使用主從復制的存儲架構(gòu)比較多澈蝙。例如奸鸯，論壇、BBS幻林、新聞網(wǎng)站這類業(yè)務(wù)愚墓，此類業(yè)務(wù)的讀操作數(shù)量是寫操作數(shù)量的 10 倍甚至 100 倍以上杠氢。

三摘能、雙機切換

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

主備復制和主從復制方案存在兩個共性的問題：

主機故障后续崖，無法進行寫操作。

如果主機無法恢復团搞，需要人工指定新的主機角色严望。

雙機切換就是為了解決這兩個問題而產(chǎn)生的，包括主備切換和主從切換兩種方案莺丑。簡單來說著蟹，這兩個方案就是在原有方案的基礎(chǔ)上增加“切換”功能，即系統(tǒng)自動決定主機角色梢莽，并完成角色切換。由于主備切換和主從切換在切換的設(shè)計上沒有差別奸披，我接下來以主備切換為例昏名，一起來看看雙機切換架構(gòu)是如何實現(xiàn)的。

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

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

主要包括兩方面：狀態(tài)傳遞的渠道轻局，以及狀態(tài)檢測的內(nèi)容。

狀態(tài)傳遞的渠道：是相互間互相連接样刷，還是第三方仲裁仑扑？

狀態(tài)檢測的內(nèi)容：例如機器是否掉電、進程是否存在置鼻、響應(yīng)是否緩慢等镇饮。

切換決策

主要包括幾方面：切換時機、切換策略箕母、自動程度储藐。

切換時機：什么情況下備機應(yīng)該升級為主機俱济？是機器掉電后備機才升級，還是主機上的進程不存在就升級钙勃，還是主機響應(yīng)時間超過 2 秒就升級蛛碌，還是 3 分鐘內(nèi)主機連續(xù)重啟 3 次就升級等。

切換策略：原來的主機故障恢復后辖源，要再次切換蔚携，確保原來的主機繼續(xù)做主機，還是原來的主機故障恢復后自動成為新的備機克饶？

自動程度：切換是完全自動的酝蜒，還是半自動的？例如彤路，系統(tǒng)判斷當前需要切換秕硝，但需要人工做最終的確認操作（例如，單擊一下“切換”按鈕）洲尊。

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

當原有故障的主機恢復后远豺，新舊主機之間可能存在數(shù)據(jù)沖突。例如坞嘀，用戶在舊主機上新增了一條 ID 為 100 的數(shù)據(jù)躯护，這個數(shù)據(jù)還沒有復制到舊的備機，此時發(fā)生了切換丽涩，舊的備機升級為新的主機棺滞，用戶又在新的主機上新增了一條 ID 為 100 的數(shù)據(jù)，當舊的故障主機恢復后矢渊，這兩條 ID 都為 100 的數(shù)據(jù)继准，應(yīng)該怎么處理？

以上設(shè)計點并沒有放之四海而皆準的答案矮男，不同的業(yè)務(wù)要求不一樣移必，所以切換方案比復制方案不只是多了一個切換功能那么簡單，而是復雜度上升了一個量級毡鉴。形象點來說崔泵，如果復制方案的代碼是 1000 行，那么切換方案的代碼可能就是 10000 行猪瞬，多出來的那 9000 行就是用于實現(xiàn)上面我所講的 3 個設(shè)計點的憎瘸。

2. 常見架構(gòu)

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

（1）互連式

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

你可以看到饲做，在主備復制的架構(gòu)基礎(chǔ)上，主機和備機多了一個“狀態(tài)傳遞”的通道遏弱，這個通道就是用來傳遞狀態(tài)信息的盆均。這個通道的具體實現(xiàn)可以有很多方式：

可以是網(wǎng)絡(luò)連接（例如，各開一個端口）漱逸，也可以是非網(wǎng)絡(luò)連接（用串口線連接）泪姨。

可以是主機發(fā)送狀態(tài)給備機，也可以是備機到主機來獲取狀態(tài)信息饰抒。

可以和數(shù)據(jù)復制通道共用肮砾，也可以獨立一條通道。

狀態(tài)傳遞通道可以是一條袋坑，也可以是多條仗处，還可以是不同類型的通道混合（例如，網(wǎng)絡(luò) + 串口）枣宫。

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

為了切換后不影響客戶端的訪問也颤，主機和備機之間共享一個對客戶端來說唯一的地址洋幻。例如虛擬 IP，主機需要綁定這個虛擬的 IP翅娶。

客戶端同時記錄主備機的地址文留，哪個能訪問就訪問哪個；備機雖然能收到客戶端的操作請求竭沫，但是會直接拒絕燥翅，拒絕的原因就是“備機不對外提供服務(wù)”。

缺點在于：

如果狀態(tài)傳遞的通道本身有故障（例如蜕提，網(wǎng)線被人不小心踢掉了）权旷，那么備機也會認為主機故障了從而將自己升級為主機，而此時主機并沒有故障贯溅，最終就可能出現(xiàn)兩個主機。

雖然可以通過增加多個通道來增強狀態(tài)傳遞的可靠性躲查，但這樣做只是降低了通道故障概率而已它浅，不能從根本上解決這個缺點，而且通道越多镣煮，后續(xù)的狀態(tài)決策會更加復雜姐霍，因為對備機來說，可能從不同的通道收到了不同甚至矛盾的狀態(tài)信息。

（2）中介式

中介式指的是在主備兩者之外引入第三方中介镊折，主備機之間不直接連接胯府，而都去連接中介，并且通過中介來傳遞狀態(tài)信息恨胚，其架構(gòu)圖如下：

對比一下互連式切換架構(gòu)骂因，我們可以看到，主機和備機不再通過互聯(lián)通道傳遞狀態(tài)信息赃泡，而是都將狀態(tài)上報給中介這一角色寒波。單純從架構(gòu)上看，中介式似乎比互連式更加復雜了升熊，首先要引入中介俄烁，然后要各自上報狀態(tài)。然而事實上级野，中介式架構(gòu)在狀態(tài)傳遞和決策上卻更加簡單了页屠，這是為何呢？

連接管理更簡單：主備機無須再建立和管理多種類型的狀態(tài)傳遞連接通道蓖柔，只要連接到中介即可辰企，實際上是降低了主備機的連接管理復雜度。

例如渊抽，互連式要求主機開一個監(jiān)聽端口蟆豫，備機來獲取狀態(tài)信息；或者要求備機開一個監(jiān)聽端口懒闷，主機推送狀態(tài)信息到備機十减；如果還采用了串口連接，則需要增加串口連接管理和數(shù)據(jù)讀取愤估。采用中介式后帮辟，主備機都只需要把狀態(tài)信息發(fā)送給中介，或者從中介獲取對方的狀態(tài)信息玩焰。無論是發(fā)送還是獲取由驹，主備機都是作為中介的客戶端去操作，復雜度會降低昔园。

狀態(tài)決策更簡單：主備機的狀態(tài)決策簡單了蔓榄，無須考慮多種類型的連接通道獲取的狀態(tài)信息如何決策的問題，只需要按照下面簡單的算法即可完成狀態(tài)決策默刚。

無論是主機還是備機甥郑，初始狀態(tài)都是備機，并且只要與中介斷開連接荤西，就將自己降級為備機澜搅，因此可能出現(xiàn)雙備機的情況伍俘。

主機與中介斷連后，中介能夠立刻告知備機勉躺，備機將自己升級為主機癌瘾。

如果是網(wǎng)絡(luò)中斷導致主機與中介斷連，主機自己會降級為備機饵溅，網(wǎng)絡(luò)恢復后妨退，舊的主機以新的備機身份向中介上報自己的狀態(tài)。

如果是掉電重啟或者進程重啟概说，舊的主機初始狀態(tài)為備機碧注，與中介恢復連接后，發(fā)現(xiàn)已經(jīng)有主機了糖赔，保持自己備機狀態(tài)不變萍丐。

主備機與中介連接都正常的情況下，按照實際的狀態(tài)決定是否進行切換放典。例如逝变，主機響應(yīng)時間超過 3 秒就進行切換，主機降級為備機奋构，備機升級為主機即可壳影。

雖然中介式架構(gòu)在狀態(tài)傳遞和狀態(tài)決策上更加簡單，但并不意味著這種優(yōu)點是沒有代價的弥臼，其關(guān)鍵代價就在于如何實現(xiàn)中介本身的高可用宴咧。如果中介自己宕機了，整個系統(tǒng)就進入了雙備的狀態(tài)径缅，寫操作相關(guān)的業(yè)務(wù)就不可用了掺栅。這就陷入了一個遞歸的陷阱：為了實現(xiàn)高可用，我們引入中介纳猪，但中介本身又要求高可用氧卧，于是又要設(shè)計中介的高可用方案……如此遞歸下去就無窮無盡了。

MongoDB 的 Replica Set 采取的就是這種方式氏堤，其基本架構(gòu)如下：

（http://img.my.csdn.net/uploads/201301/13/1358056331_2790.png）

MongoDB(M) 表示主節(jié)點沙绝，MongoDB(S) 表示備節(jié)點，MongoDB(A) 表示仲裁節(jié)點鼠锈。主備節(jié)點存儲數(shù)據(jù)闪檬，仲裁節(jié)點不存儲數(shù)據(jù)」喊剩客戶端同時連接主節(jié)點與備節(jié)點谬以，不連接仲裁節(jié)點。

幸運的是由桌，開源方案已經(jīng)有比較成熟的中介式解決方案，例如 ZooKeeper 和 Keepalived。ZooKeeper 本身已經(jīng)實現(xiàn)了高可用集群架構(gòu)行您，因此已經(jīng)幫我們解決了中介本身的可靠性問題铭乾，在工程實踐中推薦基于 ZooKeeper 搭建中介式切換架構(gòu)。

（3）模擬式

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

對比一下互連式切換架構(gòu)笛质，我們可以看到，主備機之間只有數(shù)據(jù)復制通道捞蚂，而沒有狀態(tài)傳遞通道妇押，備機通過模擬的讀寫操作來探測主機的狀態(tài)，然后根據(jù)讀寫操作的響應(yīng)情況來進行狀態(tài)決策姓迅。

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

簡單既是優(yōu)點肩杈，同時也是缺點。因為模擬式讀寫操作獲取的狀態(tài)信息只有響應(yīng)信息（例如解寝，HTTP 404扩然，超時、響應(yīng)時間超過 3 秒等）聋伦，沒有互連式那樣多樣（除了響應(yīng)信息夫偶，還可以包含 CPU 負載、I/O 負載嘉抓、吞吐量索守、響應(yīng)時間等），基于有限的狀態(tài)來做狀態(tài)決策抑片，可能出現(xiàn)偏差卵佛。

四、主主復制

主主復制指的是兩臺機器都是主機敞斋，互相將數(shù)據(jù)復制給對方截汪，客戶端可以任意挑選其中一臺機器進行讀寫操作，下面是基本架構(gòu)圖植捎。

兩臺都是主機衙解，不存在切換的概念。

客戶端無須區(qū)分不同角色的主機焰枢，隨便將讀寫操作發(fā)送給哪臺主機都可以蚓峦。

從上面的描述來看舌剂，主主復制架構(gòu)從總體上來看要簡單很多，無須狀態(tài)信息傳遞暑椰，也無須狀態(tài)決策和狀態(tài)切換霍转。復雜性：數(shù)據(jù)能夠雙向復制，而很多數(shù)據(jù)是不能雙向復制的一汽。例如：

用戶注冊后生成的用戶 ID避消，如果按照數(shù)字增長，那就不能雙向復制召夹，否則就會出現(xiàn) X 用戶在主機 A 注冊岩喷，分配的用戶 ID 是 100，同時 Y 用戶在主機 B 注冊监憎，分配的用戶 ID 也是 100纱意，這就出現(xiàn)了沖突。

庫存不能雙向復制枫虏。例如妇穴，一件商品庫存 100 件，主機 A 上減了 1 件變成 99隶债，主機 B 上減了 2 件變成 98腾它，然后主機 A 將庫存 99 復制到主機 B，主機 B 原有的庫存 98 被覆蓋死讹，變成了 99瞒滴，而實際上此時真正的庫存是 97。類似的還有余額數(shù)據(jù)赞警。

因此妓忍，主主復制架構(gòu)對數(shù)據(jù)的設(shè)計有嚴格的要求，一般適合于那些臨時性愧旦、可丟失世剖、可覆蓋的數(shù)據(jù)場景。例如笤虫，用戶登錄產(chǎn)生的 session 數(shù)據(jù)（可以重新登錄生成）旁瘫、用戶行為的日志數(shù)據(jù)（可以丟失）、論壇的草稿數(shù)據(jù)（可以丟失）等琼蚯。

小結(jié)

政府信息公開網(wǎng)站的信息存儲系統(tǒng)酬凳，你會采取哪種架構(gòu)？談?wù)勀愕姆治龊屠碛伞?/p>

評論：

政府信息網(wǎng)站使用主備或者主從架構(gòu)就可以了遭庶。信息都是人工錄入宁仔，可以補錄。數(shù)據(jù)本來對實時性要求不高峦睡，所以出了故障人工修復也來得及翎苫。所以主備就夠了权埠，如果為了照顧形象可以用主從，保證主機故障后仍然可以查拉队，不能新發(fā)