1.CAP 理論
CAP定理（CAP theorem）又被稱作布魯爾定理(Brewer's theorem)，是回加州大學伯克得分校的計算機科學家埃裏克·布魯爾（Eric Brewer）在2000年的ACM PODC上提出的一個猜想。2002 年，麻省理工學院的賽斯·吉爾伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）發表了布魯爾猜想的證明，使之成爲分佈式計算領域公認的一個定理。
第一版解釋：簡單翻譯爲：對於一個分佈式計算系統，不可能同時滿足一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三個設計約束。
第二版解釋：在一個分佈式系統（指互相連接並共享數據的節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲。
差異點：
• 第二版定義了什麼纔是 CAP 理論探討的分佈式系統，強調了兩點：interconnected 和 share data，爲何要強調這兩點呢？ 因爲分佈式系統並不一定會互聯和共享數據。最簡單的例如 Memcache 的集羣，相互之間就沒有連接和共享數據，因此 Memcache 集羣這類分佈式系統就不符合 CAP 理論探討的對象；而 MySQL 集羣就是互聯和進行數據複製的，因此是 CAP 理論探討的對象。
• 第二版強調了 write/read pair，這點其實是和上一個差異點一脈相承的。也就是說，CAP 關注的是對數據的讀寫操作，而不是分佈式系統的所有功能。例如，ZooKeeper 的選舉機制就不是 CAP 探討的對象。
• 第二版除了基本概念，三個基本的設計約束也進行了重新闡述，我來詳細分析一下。
1.1 一致性（Consistency）
對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作結果。
1.2 可用性（Availability）
非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）。
1.3 分區容錯性（Partition Tolerance）
當出現網絡分區後，系統能夠繼續“履行職責”。
1.4 CAP 應用
分佈式系統理論上不可能選擇 CA 架構，只能選擇 CP 或者 AP 架構。
2.CAP細節
理論的優點在於清晰簡潔、易於理解，但缺點就是高度抽象化，省略了很多細節，導致在將理論應用到實踐時，由於各種複雜情況，可能出現誤解和偏差，CAP 理論也不例外。如果我們沒有意識到這些關鍵的細節點，那麼在實踐中應用 CAP 理論時，就可能發現方案很難落地。
而且當談到數據一致性時，CAP、ACID、BASE 難免會被我們拿出來討論，原因在於這三者都是和數據一致性相關的理論，如果不仔細理解三者之間的差別，則可能會陷入一頭霧水的狀態，不知道應該用哪個纔好。
CAP 的具體細節，簡單對比一下 ACID、BASE 幾個概念的關鍵區別點。
2.1 CAP 關鍵細節點
2.1.1 CAP 關注的粒度是數據，而不是整個系統。
C 與 A 之間的取捨可以在同一系統內以非常細小的粒度反覆發生，而每一次的決策可能因爲具體的操作，乃至因爲牽涉到特定的數據或用戶而有所不同。
但這句話是理解和應用 CAP 理論非常關鍵的一點。CAP 理論的定義和解釋中，用的都是 system、node 這類系統級的概念，這就給很多人造成了很大的誤導，認爲我們在進行架構設計時，整個系統要麼選擇 CP，要麼選擇 AP。但在實際設計過程中，每個系統不可能只處理一種數據，而是包含多種類型的數據，有的數據必須選擇 CP，有的數據必須選擇 AP。而如果我們做設計時，從整個系統的角度去選擇 CP 還是 AP，就會發現顧此失彼，無論怎麼做都是有問題的。
以一個最簡單的用戶管理系統爲例，用戶管理系統包含用戶賬號數據（用戶 ID、密碼）、用戶信息數據（暱稱、興趣、愛好、性別、自我介紹等）。通常情況下，用戶賬號數據會選擇 CP，而用戶信息數據會選擇 AP，如果限定整個系統爲 CP，則不符合用戶信息數據的應用場景；如果限定整個系統爲 AP，則又不符合用戶賬號數據的應用場景。
所以在 CAP 理論落地實踐時，我們需要將系統內的數據按照不同的應用場景和要求進行分類，每類數據選擇不同的策略（CP 還是 AP），而不是直接限定整個系統所有數據都是同一策略。
2.1.2 CAP 是忽略網絡延遲的。
這是一個非常隱含的假設，布魯爾在定義一致性時，並沒有將延遲考慮進去。也就是說，當事務提交時，數據能夠瞬間複製到所有節點。但實際情況下，從節點 A 複製數據到節點 B，總是需要花費一定時間的。如果是相同機房，耗費時間可能是幾毫秒；如果是跨地域的機房，例如北京機房同步到廣州機房，耗費的時間就可能是幾十毫秒。這就意味着，CAP 理論中的 C 在實踐中是不可能完美實現的，在數據複製的過程中，節點 A 和節點 B 的數據並不一致。
不要小看了這幾毫秒或者幾十毫秒的不一致，對於某些嚴苛的業務場景，例如和金錢相關的用戶餘額，或者和搶購相關的商品庫存，技術上是無法做到分佈式場景下完美的一致性的。而業務上必須要求一致性，因此單個用戶的餘額、單個商品的庫存，理論上要求選擇 CP 而實際上 CP 都做不到，只能選擇 CA。也就是說，只能單點寫入，其他節點做備份，無法做到分佈式情況下多點寫入。
需要注意的是，這並不意味着這類系統無法應用分佈式架構，只是說“單個用戶餘額、單個商品庫存”無法做分佈式，但系統整體還是可以應用分佈式架構的。例如，下面的架構圖是常見的將用戶分區的分佈式架構。
我們可以將用戶 id 爲 0 ~ 100 的數據存儲在 Node 1，將用戶 id 爲 101 ~ 200 的數據存儲在 Node 2，Client 根據用戶 id 來決定訪問哪個 Node。對於單個用戶來說，讀寫操作都只能在某個節點上進行；對所有用戶來說，有一部分用戶的讀寫操作在 Node 1 上，有一部分用戶的讀寫操作在 Node 2 上。
這樣的設計有一個很明顯的問題就是某個節點故障時，這個節點上的用戶就無法進行讀寫操作了，但站在整體上來看，這種設計可以降低節點故障時受影響的用戶的數量和範圍，畢竟隻影響 20% 的用戶肯定要比影響所有用戶要好。這也是爲什麼挖掘機挖斷光纜後，支付寶只有一部分用戶會出現業務異常，而不是所有用戶業務異常的原因。
2.1.3 正常運行情況下，不存在 CP 和 AP 的選擇，可以同時滿足 CA。
CAP 理論告訴我們分佈式系統只能選擇 CP 或者 AP，但其實這裏的前提是系統發生了“分區”現象。如果系統沒有發生分區現象，也就是說 P 不存在的時候（節點間的網絡連接一切正常），我們沒有必要放棄 C 或者 A，應該 C 和 A 都可以保證，這就要求架構設計的時候既要考慮分區發生時選擇 CP 還是 AP，也要考慮分區沒有發生時如何保證 CA。
同樣以用戶管理系統爲例，即使是實現 CA，不同的數據實現方式也可能不一樣：用戶賬號數據可以採用“消息隊列”的方式來實現 CA，因爲消息隊列可以比較好地控制實時性，但實現起來就複雜一些；而用戶信息數據可以採用“數據庫同步”的方式來實現 CA，因爲數據庫的方式雖然在某些場景下可能延遲較高，但使用起來簡單。
2.1.4 放棄並不等於什麼都不做，需要爲分區恢復後做準備。
CAP 理論告訴我們三者只能取兩個，需要“犧牲”（sacrificed）另外一個，這裏的“犧牲”是有一定誤導作用的，因爲“犧牲”讓很多人理解成什麼都不做。實際上，CAP 理論的“犧牲”只是說在分區過程中我們無法保證 C 或者 A，但並不意味着什麼都不做。因爲在系統整個運行週期中，大部分時間都是正常的，發生分區現象的時間並不長。例如，99.99% 可用性（俗稱 4 個 9）的系統，一年運行下來，不可用的時間只有 50 分鐘；99.999%（俗稱 5 個 9）可用性的系統，一年運行下來，不可用的時間只有 5 分鐘。分區期間放棄 C 或者 A，並不意味着永遠放棄 C 和 A，我們可以在分區期間進行一些操作，從而讓分區故障解決後，系統能夠重新達到 CA 的狀態。
最典型的就是在分區期間記錄一些日誌，當分區故障解決後，系統根據日誌進行數據恢復，使得重新達到 CA 狀態。同樣以用戶管理系統爲例，對於用戶賬號數據，假設我們選擇了 CP，則分區發生後，節點 1 可以繼續註冊新用戶，節點 2 無法註冊新用戶（這裏就是不符合 A 的原因，因爲節點 2 收到註冊請求後會返回 error），此時節點 1 可以將新註冊但未同步到節點 2 的用戶記錄到日誌中。當分區恢復後，節點 1 讀取日誌中的記錄，同步給節點 2，當同步完成後，節點 1 和節點 2 就達到了同時滿足 CA 的狀態。
而對於用戶信息數據，假設我們選擇了 AP，則分區發生後，節點 1 和節點 2 都可以修改用戶信息，但兩邊可能修改不一樣。例如，用戶在節點 1 中將愛好改爲“旅遊、美食、跑步”，然後用戶在節點 2 中將愛好改爲“美食、遊戲”，節點 1 和節點 2 都記錄了未同步的愛好數據，當分區恢復後，系統按照某個規則來合併數據。例如，按照“最後修改優先規則”將用戶愛好修改爲“美食、遊戲”，按照“字數最多優先規則”則將用戶愛好修改爲“旅遊，美食、跑步”，也可以完全將數據衝突報告出來，由人工來選擇具體應該採用哪一條。
2.2 ACID
ACID 是數據庫管理系統爲了保證事務的正確性而提出來的一個理論，ACID 包含四個約束，下面我來解釋一下。
2.2.1 Atomicity（原子性）
一個事務中的所有操作，要麼全部完成，要麼全部不完成，不會在中間某個環節結束。事務在執行過程中發生錯誤，會被回滾到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
2.2.2 Consistency（一致性）
在事務開始之前和事務結束以後，數據庫的完整性沒有被破壞。
2.2.3 Isolation（隔離性）
數據庫允許多個併發事務同時對數據進行讀寫和修改的能力。隔離性可以防止多個事務併發執行時由於交叉執行而導致數據的不一致。事務隔離分爲不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重複讀（repeatable read）和串行化（Serializable）。
2.2.4 Durability（持久性）
事務處理結束後，對數據的修改就是永久的，即便系統故障也不會丟失。
可以看到，ACID 中的 A（Atomicity）和 CAP 中的 A（Availability）意義完全不同，而 ACID 中的 C 和 CAP 中的 C 名稱雖然都是一致性，但含義也完全不一樣。ACID 中的 C 是指數據庫的數據完整性，而 CAP 中的 C 是指分佈式節點中的數據一致性。再結合 ACID 的應用場景是數據庫事務，CAP 關注的是分佈式系統數據讀寫這個差異點來看，其實 CAP 和 ACID 的對比就類似關公戰秦瓊，雖然關公和秦瓊都是武將，但其實沒有太多可比性。
2.3 BASE
BASE 是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency），核心思想是即使無法做到強一致性（CAP 的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性。
2.3.1 基本可用（Basically Available）
分佈式系統在出現故障時，允許損失部分可用性，即保證核心可用。
這裏的關鍵詞是“部分”和“核心”，具體選擇哪些作爲可以損失的業務，哪些是必須保證的業務，是一項有挑戰的工作。例如，對於一個用戶管理系統來說，“登錄”是核心功能，而“註冊”可以算作非核心功能。因爲未註冊的用戶本來就還沒有使用系統的業務，註冊不了最多就是流失一部分用戶，而且這部分用戶數量較少。如果用戶已經註冊但無法登錄，那就意味用戶無法使用系統。例如，充了錢的遊戲不能玩了、雲存儲不能用了……這些會對用戶造成較大損失，而且登錄用戶數量遠遠大於新註冊用戶，影響範圍更大。
2.3.2 軟狀態（Soft State）
允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。這裏的中間狀態就是 CAP 理論中的數據不一致。
2.3.3 最終一致性（Eventual Consistency）
系統中的所有數據副本經過一定時間後，最終能夠達到一致的狀態。
這裏的關鍵詞是“一定時間” 和 “最終”，“一定時間”和數據的特性是強關聯的，不同的數據能夠容忍的不一致時間是不同的。舉一個微博系統的例子，用戶賬號數據最好能在 1 分鐘內就達到一致狀態，因爲用戶在 A 節點註冊或者登錄後，1 分鐘內不太可能立刻切換到另外一個節點，但 10 分鐘後可能就重新登錄到另外一個節點了；而用戶發佈的最新微博，可以容忍 30 分鐘內達到一致狀態，因爲對於用戶來說，看不到某個明星發佈的最新微博，用戶是無感知的，會認爲明星沒有發佈微博。“最終”的含義就是不管多長時間，最終還是要達到一致性的狀態。
BASE 理論本質上是對 CAP 的延伸和補充，更具體地說，是對 CAP 中 AP 方案的一個補充。前面在剖析 CAP 理論時，提到了其實和 BASE 相關的兩點：
• CAP 理論是忽略延時的，而實際應用中延時是無法避免的。
這一點就意味着完美的 CP 場景是不存在的，即使是幾毫秒的數據複製延遲，在這幾毫秒時間間隔內，系統是不符合 CP 要求的。因此 CAP 中的 CP 方案，實際上也是實現了最終一致性，只是“一定時間”是指幾毫秒而已。
• AP 方案中犧牲一致性只是指分區期間，而不是永遠放棄一致性。
這一點其實就是 BASE 理論延伸的地方，分區期間犧牲一致性，但分區故障恢復後，系統應該達到最終一致性。
綜合上面的分析，ACID 是數據庫事務完整性的理論，CAP 是分佈式系統設計理論，BASE 是 CAP 理論中 AP 方案的延伸。
3. FMEA方法，排除架構可用性隱患的利器
3.1 FMEA 介紹
FMEA（Failure mode and effects analysis，故障模式與影響分析）又稱爲失效模式與後果分析、失效模式與效應分析、故障模式與後果分析等，專欄採用“故障模式與影響分析”，因爲這個中文翻譯更加符合可用性的語境。FMEA 是一種在各行各業都有廣泛應用的可用性分析方法，通過對系統範圍內潛在的故障模式加以分析，並按照嚴重程度進行分類，以確定失效對於系統的最終影響。
FMEA 最早是在美國軍方開始應用的，20 世紀 40 年代後期，美國空軍正式採用了 FMEA。儘管最初是在軍事領域建立的方法，但 FMEA 方法現在已廣泛應用於各種各樣的行業，包括半導體加工、餐飲服務、塑料製造、軟件及醫療保健行業。FMEA 之所以能夠在這些差異很大的領域都得到應用，根本原因在於 FMEA 是一套分析和思考的方法，而不是某個領域的技能或者工具。
回到軟件架構設計領域，FMEA 並不能指導我們如何做架構設計，而是當我們設計出一個架構後，再使用 FMEA 對這個架構進行分析，看看架構是否還存在某些可用性的隱患。
3.2 FMEA 方法
在架構設計領域，FMEA 的具體分析方法是：
• 給出初始的架構設計圖。
• 假設架構中某個部件發生故障。
• 分析此故障對系統功能造成的影響。
• 根據分析結果，判斷架構是否需要進行優化。
FMEA 分析的方法其實很簡單，就是一個 FMEA 分析表，常見的 FMEA 分析表格包含下面部分。
3.2.1 功能點
當前的 FMEA 分析涉及的功能點，注意這裏的“功能點”指的是從用戶角度來看的，而不是從系統各個模塊功能點劃分來看的。例如，對於一個用戶管理系統，使用 FMEA 分析時 “登錄”“註冊”纔是功能點，而用戶管理系統中的數據庫存儲功能、Redis 緩存功能不能作爲 FMEA 分析的功能點。
3.2.2 故障模式
故障模式指的是系統會出現什麼樣的故障，包括故障點和故障形式。需要特別注意的是，這裏的故障模式並不需要給出真正的故障原因，我們只需要假設出現某種故障現象即可，例如 MySQL 響應時間達到 3 秒。造成 MySQL 響應時間達到 3 秒可能的原因很多：磁盤壞道、慢查詢、服務器到 MySQL 的連接網絡故障、MySQL bug 等，我們並不需要在故障模式中一一列出來，而是在後面的“故障原因”一節中列出來。因爲在實際應用過程中，不管哪種原因，只要現象是一樣的，對業務的影響就是一樣的。
此外，故障模式的描述要儘量精確，多使用量化描述，避免使用泛化的描述。例如，推薦使用“MySQL 響應時間達到 3 秒”，而不是“MySQL 響應慢”。
3.2.3 故障影響
當發生故障模式中描述的故障時，功能點具體會受到什麼影響。常見的影響有：功能點偶爾不可用、功能點完全不可用、部分用戶功能點不可用、功能點響應緩慢、功能點出錯等。
故障影響也需要儘量準確描述。例如，推薦使用“20% 的用戶無法登錄”，而不是“大部分用戶無法登錄”。要注意這裏的數字不需要完全精確，比如 21.25% 這樣的數據其實是沒有必要的，我們只需要預估影響是 20% 還是 40%。
3.2.4 嚴重程度
嚴重程度指站在業務的角度故障的影響程度，一般分爲“致命 / 高 / 中 / 低 / 無”五個檔次。嚴重程度按照這個公式進行評估：嚴重程度 = 功能點重要程度 × 故障影響範圍 × 功能點受損程度。同樣以用戶管理系統爲例：登錄功能比修改用戶資料要重要得多，80% 的用戶比 20% 的用戶範圍更大，完全無法登錄比登錄緩慢要更嚴重。因此我們可以得出如下故障模式的嚴重程度。
• 致命：超過 70% 用戶無法登錄。
• 高：超過 30% 的用戶無法登錄。
• 中：所有用戶登錄時間超過 5 秒。
• 低：10% 的用戶登錄時間超過 5 秒。
• 中：所有用戶都無法修改資料。
• 低：20% 的用戶無法修改頭像。
對於某個故障的影響到底屬於哪個檔次，有時會出現一些爭議。例如，“所有用戶都無法修改資料”，有的人認爲是高，有的人可能認爲是中，這個沒有絕對標準，一般建議相關人員討論確定即可。也不建議花費太多時間爭論，爭執不下時架構師裁定即可。
3.2.5 故障原因
“故障模式”中只描述了故障的現象，並沒有單獨列出故障原因。主要原因在於不管什麼故障原因，故障現象相同，對功能點的影響就相同。那爲何這裏還要單獨將故障原因列出來呢？主要原因有這幾個：
• 不同的故障原因發生概率不相同
例如，導致 MySQL 查詢響應慢的原因可能是 MySQL bug，也可能是沒有索引。很明顯“MySQL bug”的概率要遠遠低於“沒有索引”；而不同的概率又會影響我們具體如何應對這個故障。
• 不同的故障原因檢測手段不一樣
例如，磁盤壞道導致 MySQL 響應慢，那我們需要增加機器的磁盤壞道檢查，這個檢查很可能不是當前系統本身去做，而是另外運維專門的系統；如果是慢查詢導致 MySQL 慢，那我們只需要配置 MySQL 的慢查詢日誌即可。
• 不同的故障原因的處理措施不一樣
例如，如果是 MySQL bug，我們的應對措施只能是升級 MySQL 版本；如果是沒有索引，我們的應對措施就是增加索引。
3.2.6 故障概率
這裏的概率就是指某個具體故障原因發生的概率。例如，磁盤壞道的概率、MySQL bug 的概率、沒有索引的概率。一般分爲“高 / 中 / 低”三檔即可，具體評估的時候需要有以下幾點需要重點關注。
• 硬件
硬件隨着使用時間推移，故障概率會越來越高。例如，新的硬盤壞道機率很低，但使用了 3 年的硬盤，壞道機率就會高很多。
• 開源系統
成熟的開源系統 bug 率低，剛發佈的開源系統 bug 率相比會高一些；自己已經有使用經驗的開源系統 bug 率會低，剛開始嘗試使用的開源系統 bug 率會高。
• 自研系統
和開源系統類似，成熟的自研系統故障概率會低，而新開發的系統故障概率會高。
高中低是相對的，只是爲了確定優先級以決定後續的資源投入，沒有必要絕對量化，因爲絕對量化是需要成本的，而且很多時候都沒法量化。例如，XX 開源系統是 3 個月故障一次，還是 6 個月才故障一次，是無法評估的。
3.2.7 風險程度
風險程度就是綜合嚴重程度和故障概率來一起判斷某個故障的最終等級，風險程度 = 嚴重程度 × 故障概率。因此可能出現某個故障影響非常嚴重，但其概率很低，最終來看風險程度就低。“某個機房業務癱瘓”對業務影響是致命的，但如果故障原因是“地震”，那概率就很低。例如，廣州的地震概率就很低，5 級以上地震的 20 世紀才 1 次（1940 年）；如果故障的原因是“機房空調燒壞”，則概率就比地震高很多了，可能是 2 年 1 次；如果故障的原因是“系統所在機架掉電”，這個概率比機房空調又要高了，可能是 1 年 1 次。同樣的故障影響，不同的故障原因有不同的概率，最終得到的風險級別就是不同的。
3.2.8 已有措施
針對具體的故障原因，系統現在是否提供了某些措施來應對，包括：檢測告警、容錯、自恢復等。
• 檢測告警:最簡單的措施就是檢測故障，然後告警，系統自己不針對故障進行處理，需要人工干預。
• 容錯:檢測到故障後，系統能夠通過備份手段應對。例如，MySQL 主備機，當業務服務器檢測到主機無法連接後，自動連接備機讀取數據。
• 自恢復:檢測到故障後，系統能夠自己恢復。例如，Hadoop 檢測到某臺機器故障後，能夠將存儲在這臺機器的副本重新分配到其他機器。當然，這裏的恢復主要還是指“業務”上的恢復，一般不太可能將真正的故障恢復。例如，Hadoop 不可能將產生了磁盤壞道的磁盤修復成沒有壞道的磁盤。
3.2.9 規避措施
規避措施指爲了降低故障發生概率而做的一些事情，可以是技術手段，也可以是管理手段。例如：
• 技術手段：爲了避免新引入的 MongoDB 丟失數據，在 MySQL 中冗餘一份。
• 管理手段：爲了降低磁盤壞道的概率，強制統一更換服務時間超過 2 年的磁盤。
3.2.10 解決措施
解決措施指爲了能夠解決問題而做的一些事情，一般都是技術手段。例如：
• 爲了解決密碼暴力破解，增加密碼重試次數限制。
• 爲了解決拖庫導致數據泄露，將數據庫中的敏感數據加密保存。
• 爲了解決非法訪問，增加白名單控制。
一般來說，如果某個故障既可以採取規避措施，又可以採取解決措施，那麼我們會優先選擇解決措施，畢竟能解決問題當然是最好的。但很多時候有些問題是系統自己無法解決的，例如磁盤壞道、開源系統 bug，這類故障只能採取規避措施；系統能夠自己解決的故障，大部分是和系統本身功能相關的。
3.2.11 後續規劃
綜合前面的分析，就可以看出哪些故障我們目前還缺乏對應的措施，哪些已有措施還不夠，針對這些不足的地方，再結合風險程度進行排序，給出後續的改進規劃。這些規劃既可以是技術手段，也可以是管理手段；可以是規避措施，也可以是解決措施。同時需要考慮資源的投入情況，優先將風險程度高的系統隱患解決。
例如：
• 地震導致機房業務中斷：這個故障模式就無法解決，只能通過備份中心規避，儘量減少影響；而機櫃斷電導致機房業務中斷：可以通過將業務機器分散在不同機櫃來規避。
• 敏感數據泄露：這個故障模式可以通過數據庫加密的技術手段來解決。
• MongoDB 斷電丟數據：這個故障模式可以通過將數據冗餘一份在 MySQL 中，在故障情況下重建數據來規避影響。
4.高可用存儲架構：雙機架構
高可用存儲架構中常見的雙機架構，分別爲主備複製、主從複製、雙機切換和主主複製。
5.高可用存儲架構：集羣和分區
6.如何設計計算高可用架構
計算高可用的本質是通過冗餘來規避部分故障的風險。
計算高可用架構的設計複雜度主要體現在任務管理方面。因此，計算高可用架構設計的關鍵點有下面兩點。
6.1 哪些服務器可以執行任務
第一種方式：每個服務器都可以執行任務。
第二種方式：只有特定服務器（通常叫“主機”）可以執行任務。當執行任務的服務器故障後，系統需要挑選新的服務器來執行任務。
6.2 任務如何重新執行
第一種策略是對於已經分配的任務即使執行失敗也不做任何處理，系統只需要保證新的任務能夠分配到其他非故障服務器上執行即可。
第二種策略是設計一個任務管理器來管理需要執行的計算任務，服務器執行完任務後，需要向任務管理器反饋任務執行結果，任務管理器根據任務執行結果來決定是否需要將任務重新分配到另外的服務器上執行。
接下來，我將詳細闡述常見的計算高可用架構：主備、主從和集羣。
7.業務高可用的保障：異地多活架構
7.1 什麼是異地多活？
• 異地多活：異地指不同地理位置，多活指不同地理位置的系統都是活躍的，都能夠提供業務服務。
• 異地多活是爲了解決極端場景下所有服務器都出現故障時業務不受影響，或者業務在幾分鐘內就能夠快速恢復而設計的。
• 異地多活的優點：功能強大、提供更好的體驗、可以減少業務中斷帶來的損失
• 異地多活的缺點：代價高昂、設計複雜
7.2 應用場景
• 無法承受異地多活帶來的複雜度和成本時可以只做異地備份，不做異地多活
• 業務中斷後對用戶影響很大的系統需要做異地多活
• 業務規模很大，中斷後影響收入的系統需要做異地多活
7.3 架構模式
根據地理位置上的距離分爲同城異區、跨城異地、跨國異地3種架構模式
7.3.1 同城異區
• 定義：將業務部署在同一個城市不同區的多個機房
• 優缺點：設計複雜度非常低、成本相對較低、極端災難無法應對
• 應用場景：應對機房級別故障的最優架構
7.3.2 跨城異地
• 定義：業務部署在不同城市的多個機房，而且距離最好要遠一些
• 優缺點：可以有效應對範圍較大的極端災難、架構複雜度很高
• 應用場景：對數據一致性要求不那麼高，或者數據不怎麼改變，或者即使數據丟失影響也不大的業務
7.3.3 跨國異地
• 定義：業務部署在不同國家的多個機房
• 優缺點：不是真正意義的多活、適合特殊類型業務
• 應用場景：爲不同地區的用戶提供服務、只讀類的業務
8.異地多活設計4大技巧
異地多活的本質：通過異地的數據冗餘，來保證在極端異常的情況下業務也能夠正常提供給用戶，異地多活架構設計的核心是數據同步
設計核心思想：採用多種手段，保證絕大部分用戶的核心業務異地多活
8.1 技巧一：保證核心業務的異地多活
• 不要陷入『保證所有業務都能“異地多活”』的思維誤區
• 識別核心業務，優先實現核心業務的異地多活架構
8.2 技巧二：保證核心數據最終一致性
• 不要陷入『所有數據都實時同步』的思維誤區
• 物理距離導致無法實現數據快速同步的問題是無解的，只能儘量減少影響
• 儘量減少機房距離、儘量減少數據同步、只保證最終一致性
3、技巧三：採用多種手段同步數據
• 不要陷入『只使用存儲系統的同步功能』的思維誤區
• 多種手段配合存儲系統的同步來使用，或者不採用存儲系統的同步方案
4、技巧四：只保證絕大部分用戶的異地多活
• 不要陷入『我要保證業務 100% 可用』的思維誤區
• 異地多活也無法保證 100% 的業務可用
• 可以採取一些措施進行安撫或者補償受影響的用戶
9.跨城異地多活架構的設計流程
9.1 第一步：業務分級
• 按照一定的標準將業務進行分級，挑選出核心的業務
• 分級標準：訪問量大的、核心業務、產生大量收入的
9.2 第二步：數據分類
• 對核心業務相關的數據進一步分析，識別所有的數據及數據特徵
• 常見數據特徵分析緯度：數據量、數據唯一性、實時性、可丟失性、可恢復性
9.3 第三步：數據同步
• 根據不同的數據設計不同的同步方案
• 常見數據同步方案：存儲系統同步、消息隊列同步、重複生成
9.4 第四步：異常處理
• 假設在出現同步延遲、數據丟失、數據不一致等問題時，系統將採取什麼措施來應對
• 目的是避免整體業務不可用、在問題恢復後修正異常數據、安撫用戶彌補損失
• 常見異常處理措施：多通道同步、同步和訪問結合、日誌記錄、用戶補償
10.如何應對接口級的故障？
接口故障是指機器並沒有停機，網絡也正常。但業務出現問題，比如響應緩慢，超時等異常。這種問題一般都是服務器壓力過大導致的。
解決方案：
10.1 降級
就是停掉一些非核心的業務功能。例如雙11的時候，訂單數量不顯示。不支持售後服務等。保證核心功能的使用。
10.2 熔斷
熔斷和降級的區別：
• 降級針對的是應對自身系統故障。
• 熔斷是應對外部系統故障情況。例如果A系統的X功能依賴B系統的接口，但B系統接口執行緩慢導致A系統的大量線程被卡住，A系統將會掛掉。處理方式就是當A系統的X功能有調用B系統接口前直接返回錯誤，不進行調用。
• 熔斷機制實現關鍵就是有一個統一的API調用層，由API調用層來進行採樣分析。接口調用散落在代碼的各處就沒法處理。
10.3 限流：
基於請求的限流：簡單來說就是單位時間內允許的請求數量。
基於資源的限流：是從系統內部資源考慮的，常見的內部資源有：連接數，文件句炳，線程數，請求隊列等。
例如使用隊列接收請求，當超過隊列大小時直接拒絕後面的請求。
10.4 排隊：想想12306就明白了
由於排隊需要臨時緩存大量的業務請求（夯住請求不直接不響應）。所以一般都需要獨立的消息隊列系統緩存。