高可用架構（上）

1. 背景

在學習完各種高性能發實作方案後，就需要對三大複雜度一直的高可用進行開刀了，在高可用方面主要有哪些東西是我們需要考慮的呢？接下來将從三個方面逐一分析。

2. 理論

在設計高可用架構理論方面，我們主要有2個方向選擇，分别是CAP理論和BASE理論，那什麼是CAP，什麼是BASE呢？ 這個還是要好好分析一下。

2.1 CAP

• C（Consistence）：一緻性
• A（Availability）：可用性
• P（Partition Tolerance）：分區容錯性

一緻性：指的是從所有節點擷取的資料都是最新的（最新，那就是每個節點資料都是最新的資料，相同的）。

可用性：非故障節點在合理時間内傳回合理響應。這個主要是為了排除一些非正常響應，如：逾時，或者錯誤的結果

分區容錯性：在發生網絡異常時，系統能夠繼續保持任務運作

CAP理論有三個，但是在分布式系統中來說，隻能選擇其中兩個。多系統網絡中，我們無法保證網絡100%正常，是以必須要選擇P，保持系統繼續運作，然後才是在C、A之間做取舍。如果選擇CP， 那就是需要保證資料的一緻，當無法保證資料一緻時，就要對異常節點剔除，就無法保證系統可用性。當選擇AP，當網絡波動時，資料無法同步，無法保持最新資料，但系統可以通路。

通過上面的描述，有沒有發現一個問題？這些理論都是針對資料來說的，當CP時，資料保證了一緻，當AP時，資料不一緻。我們有一個誤區，認為系統設計一定要選AP，或者CP。其實這樣是不正确的。因為在同一個系統中，可能部分資料需要保證AP，有一部分資料需要保證CP，例如：關于金額的資料則需要保證AP，但是使用者相關昵稱、簡介可以使用AP。

是以，在系統正常運作的時候，是不存在選AP，還是CP的，我們應該同時關注CA。CAP的理論的前提是發生了網絡分區，但是，當網絡正常時，我們沒有必要放棄A或C，我們應該同時滿足。

2.2 BASE

• B（Basically Available）：基本可用
• S（ Soft State）：軟狀态
• E（Eventual Consistency）：最終一緻性

基本可用：分布式系統發生故障的時候，保證系統能夠基本運作，允許損失部分可用性

軟狀态：過渡期，資料處于某中非最終狀态。可以了解為：資料不一緻

最終一緻性：系統中的資料經過一段時間後，最終達到一緻的狀态（非實時一緻）

BASE理論是對CAP理論的一種補充，在CAP中，C大多數指的情況是強一緻性，在同一時刻，從所有節點擷取的資料是相同的。而在BASE中，則通過軟狀态，和最終一緻性來保證系統可用，而非在同一刻資料相同，而是通過一段時間後，所有節點資料相同。或者說，當系統發生分區故障時，資料不一緻也可以使用，而最後通過通過，達到所有節點資料一緻。

3. 接口層面

當在理論方面選擇完可用性後，我們就需要在接口層面來考慮系統的可用性了。不然，一個接口調用，就搞挂系統，這樣可就丢人啦。

通常，我們從接口層面考慮可用性主要分為4個方面，相信大家也是耳熟能詳。分别是：熔斷，限流，降級，排隊。接下來就從這4個方面介紹。

3.1 熔斷

熔斷，這就和我們生活中的保險絲很像，當功率過大的時候，保險絲就會斷掉，防止功率過大，引起火災。我們在進行接口設計時，也需要考慮熔斷，當系統接口調用失敗，達到一定失敗率或壓力時，應該熔斷系統。這裡的熔斷，不是指挂掉接口，而是快速響應。我們通過自定義響應内容，快速傳回結果，響應用戶端。熔斷的核心理念也就是快速響應，保證系統可用。

3.2 限流

限流。這個就像我們周五進地鐵，由于人多，防止地鐵裡的人員發生踩踏，擁擠事件，就在地鐵口弄幾個架子，讓人慢慢排隊，減小入口流量，保證地鐵裡的人流能夠正常運作。限流和地鐵這個沒有大的差別，防止系統應對過大的流量，壓垮系統，則通過閘口，控制進入系統的流量，這樣可以使得系統在一個合理的流量内運作，保證了系統的正常運作。我們通過這樣可以看得出來：限流是通過外部方式，來解決系統可用性。

3.3 降級

降級，那就是在流量高峰期間，關閉或減少系統其他功能，保證系統的核心功能可用。舉個栗子：那就是淘寶雙11的時候了，隻能下單，而不能就行查單/或者隻能查詢最近幾天的單。為什麼呢？因為使用者下單後可能進行大量的查單操作，占用大量系統資源，那就會影響下單，影響業務收入，這樣就得不償失。通過關閉查單，保證下單可用，這樣就保證了核心系統的可用。

3.4 排隊

排隊，顧名思義，就是排隊。就像網紅奶茶店，大家都擠着去買奶茶，人員忙不過來，那咋辦？ 那大家就排隊呗，在這等着，然後等到你的時候，在給你響應。在系統中，我們可以通過暫緩使用者請求，排在隊列中，讓使用者等待，限制處理量，等處理後在給使用者響應。大家應該也有所發現，排隊和限流還是蠻像的，限流是直接拒絕，而排隊，是讓使用者等待。

4. 存儲

從理論，到接口，那麼接下來就是存儲方面的高可用。在網際網路中，大量的使用者，大量的資料，帶來的極多挑戰，那麼，我們到底有什麼方案可以保證存儲高可用呢？

存儲高可用的本質都是通過将資料複制到多個儲存設備，通過資料備援的方式來實作高可用。其主要的複雜性展現在：資料同步延時和資料複制中斷帶來的資料不一緻問題。是以我們也主要從四個方面考慮問題。1、資料如何複制，2、各個節點的職責，3、如果應對複制延遲，4、如果應對資料複制中斷。

4.1 切換方式

常見的分布式方案有；主從，主備，主主

4.1.1 主備

主備，從字面意思了解，就是一個主節點，一個備機。 主節點用來處理所有的操作。備機從主節點備份資料，但是不對外提供服務。這種方式就是簡單，切換主，備用戶端無感覺。缺點就是：備機僅僅用來備份，有些浪費。

4.1.2 主從

主從，從字面了解就是一個主人，一個随從。随從和備機還是有差別的，随從需要幹活，備份不需要。主從和主備相似，隻是從機需要提供查詢服務。這中方式彌補了主備方式備機浪費的缺點，但也帶來了新的問題，主從複制延遲問題，用戶端需要根據情況切換到主機或備機。

4.1.3 主主

主主，顧名思義，就是兩個節點都是主節點。雙主帶來的好處就是任何一個節點都可以進行讀寫操作，但缺點也顯而易見。雙主節點需要對對方的資料進行同步，這樣就帶來了同步延時的問題，同時，在同步的時候還會帶來資料重複的問題。如：在A服務注冊了手機号為F的使用者，在B服務業注冊了手機号為的使用者，在合并時如何處理的。是以，在未考慮複雜性的時候，主主更适用于資料具有可重複性，可丢失的場景。

4.2 雙機切換

我們從主備和主從的方案中發現，當主節點挂掉後，就無法在對外提供服務。這樣就會導緻服務當機，那麼我們就要采取一個合适的方案，來進行新的主節點的選取，那麼就涉及到了輕按兩下切換

要設計切換方案，我們就要從這幾個方面考慮：

4.2.1 主備間狀态判斷

主要包括：1、狀态傳遞的管道，也就是通過什麼樣的方式來傳遞内容。 2、 狀态檢測的内容：主要是通過什麼東西來判斷主節點是否挂掉，如：斷電，程序死亡？

4.2.2 切換的決策

切換決策主要包含幾個方面：1、什麼時候切換，2、如何切換，3、切換的方式如何？

4.2.3 資料沖突問題

我們在切換過程中，可能主備/主從之間資料還未完全同步，如何保證切換後資料一緻，這個就有點類似上面的主主方案了。

5. 總結

以上分享的是高可用架構理論，接口，存儲方面的理論知識，在設計高可用的時候還是有許多要考慮的。如果有什麼問題，歡迎指正，讨論

你的每一個點贊，我都當做喜歡