本系列是極客時間《從0開始學架構》的讀書筆記。

接下來就是高可用部分了。

一般來講，相對於高效能來說，高可用的複雜度更高，因為高可用的異常情況太多，只要稍有疏漏，就會埋下隱患。當然只是對一般情況而言。

對於高效能來講，有一種方法是採用叢集，來將海量請求分發到不同的機器上，從而提高效能。相對應的，高可用也可採用叢集，來避免單點出現故障時，服務不可用。總結下，高可用場景下采用叢集的原理是增加了冗餘。

一般稱這種叢集為分散式系統。
分散式系統可橫向擴充套件，是為了解決單點瓶頸問題，提高高併發量下的可用性（依我看，就是高效能叢集的應用場景，當然問題角度不同）。
分散式系統還可保證高可用性，是為了解決單點故障問題，保證部分節點出現問題時服務依然可用。

以下的內容都是對於上述第二點而言的。

高可用叢集的複雜度表現在資料延遲和資料的一致性兩方面。CAP理論就是關於資料一致性的。

一、CAP

對應《22 | 想成為架構師，你必須知道CAP理論》《23 | 想成為架構師，你必須掌握的CAP細節》

CAP定理，又稱布魯爾定理，是設計分散式系統時必須掌握的理論。

C：Consistency，一致性，A：Availability，可用性，P：Partition tolerance，分割槽容錯性。

CAP理論

1.在一個分散式系統（互相連線並共享資料的節點的集合）中，當涉及讀寫操作時，只能保證滿足CAP中的三者之二。
關鍵點是，首先對分散式系統的定義作了限制，如果不互聯或不共享資料的分散式系統，則不適合CAP理論。另一個是關注的是資料的讀寫操作，不關注其它功能。

2.Consistency，一致性，指的是，對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作結果。
Availability，可用性，指的是，非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）。注意並沒有說“正確”的響應。
Partition tolerance，分割槽容忍性，指的是，當出現網路分割槽後，系統能夠繼續“履行職責”。

CAP應用

在分散式系統中，分割槽總是不可避免的，所以必須選擇P，只能是CP或AP。如果是CA的話，當出現分割槽時，若要保證C，則系統需要禁止寫入，當寫入請求時，系統返回的響應不合理，違背A。反過來要保證A，就會違背C。

CAP細節

1.CAP關注的的粒度是資料

，不是系統。也就是說，在設計分散式系統的時候，對於整個系統，其實並不限定一定是CP或AP。對於不同的資料，會選擇不同的組合。
2.CAP是忽略網路延時的。這意味著，C在實踐中是不可能完美實現的，由於存在網路時延，導致在資料複製過程中，可能存在不一致現象。所以理論上選擇CP，而CP都做不到，這時只能選擇CA。即分散式情況下，只做到單點寫入，其他節點做備份，做不到多點寫入。
3.正常情況下，不存在CP或AP，則可滿足CA。按照CAP理論，在出現分割槽時只能選擇CP或AP，但是系統沒有分割槽時，就可以考慮CA。也就是說在設計分散式系統時，既要考慮在分割槽出現時選擇CP還是AP，也要考慮正常情況下如何保證CA。
4.放棄不等於什麼都不做，需要為分割槽後恢復做準備。

其他資料一致性理論

ACID是資料庫管理系統（DBMS）為保證事務的正確性，而提出的理論。其中I隔離性又可分為讀未提交、讀提交、可重複讀、序列化。
ACID關注的是資料庫事務，而CAP關注的是分散式系統中資料的讀寫。

BASE，指的是，基本可用（Basically Available）、軟狀態（Soft State）、最終一致性（Eventual Consistency），即系統無法做到強一致性（CAP中的C），但可以通過適合的方式做到最終一致性。
可見，BASE理論是CAP理論的延伸和補充。更具體的是，對AP方案的一個補充，因為主要是對一致性作了補充定義。
由於時延，所以完美CP不存在。所以CP方案實際上是實現了最終一致性。
AP方案犧牲了C，但是隻是在分割槽時犧牲了一致性，當分割槽故障恢復後，還是要保證最終一致性。

談點個人的感受。第一次看CAP理論時，我有點暈。在看完整個課程後再來看，還是發現能夠和之後所講的內容有所印證。但是由於實際上缺少真正的架構設計經驗，對於CAP理論還是未能完全掌握。

二、FMEA

對應《24 | FMEA方法，排除架構可用性隱患的利器》

既然高可用架構很難設計，複雜度很高，那怎麼才能保證設計時能夠考慮到所有的異常情況呢？

FMEA，故障模式與影響分析。

具體分析方法是：
1.給出初始的設計架構圖。
2.假設架構中的某個部件發生故障。
3.分析此故障對系統的影響。
4.根據分析結果，確定是否需要對架構做優化。

在一個FMEA表格中，需要包含：
1.功能點。是從使用者角度來看的。
2.故障模式。故障功能點加故障模式，只需要描述現象即可。
3.故障影響。功能點會受到什麼影響，描述儘量準確，但不需要很精確。
4.嚴重程度。站在業務的角度，會受到的影響程度。
5.故障原因。
6.故障概率。
7.風險程度。綜合嚴重程度和故障概率，來最終判斷一個故障的等級。
8.已有措施。
9.規避措施。
10.解決方案。
11.後續規劃。