一、CAP理論
CAP理論：在一個分佈式系統中，最多隻能滿足C、A、P中的2個。
CAP含義：
C：Consistency 一致性：同一數據的多個副本是否實時相同。all nodes see the same data at the same time
A：Availability 可用性：一定時間內，系統能返回一個明確的結果 則稱爲該系統可用。Reads and writes always succeed
P：Partition tolerance 分區容錯性：分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。the system continues to operate despite arbitrary message loss or failure of part of the system
而通常情況下，我們都必須要滿足AP，所以只能犧牲C。
犧牲一致性換取可用性和分區容錯性。
犧牲一致性的意思是，把強一致換成弱一致。只要數據最終能一致就好了，並不要實時一致。
二、BASE理論
主要就是分佈式系統中最CAP怎麼取捨怎麼平衡的一個理論
BA：Basic Available 基本可用
基本可用是指分佈式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。
電商大促時，爲了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。
基本可用BA和高可用HA的區別是：
1.響應時間可以更長。
2.給部分用戶返回一個降級頁面。返回降級頁面仍然是返回明確結果。
S：Soft State：柔性狀態。同一數據的不同副本的狀態，不用實時一致。
E：Eventual Consisstency：最終一致性。 同一數據的不同副本的狀態，不用實時一致，但一定要保證經過一定時間後最終是一致的。
三、FLP
參考：https://wohugb.github.io/blockchain_guide/distribute_system/flp/
1.FLP 不可能原理
原理：在網絡可靠，但允許節點失效（即便只有一個）的最小化異步模型系統中，不存在一個可以解決一致性問題的確定性共識算法（No completely asynchronous consensus protocol can tolerate even a single unannounced process death）。
提出並證明該定理的論文《Impossibility of Distributed Consensus with One Faulty Process》是由 Fischer，Lynch 和 Patterson 三位科學家於 1985 年發表，該論文後來獲得了 Dijkstra（就是發明最短路徑算法的那位計算機科學家）獎。
FLP 不可能原理告訴我們，不要浪費時間，去試圖爲異步分佈式系統設計面向任意場景的共識算法。
2.在分佈式系統中，同步和異步這兩個術語存在特殊的含義
同步
是指系統中的各個節點的時鐘誤差存在上限；
並且消息傳遞必須在一定時間內完成，否則認爲失敗；
同時各個節點完成處理消息的時間是一定的。
因此同步系統中可以很容易地判斷消息是否丟失。
異步
則意味着系統中各個節點可能存在較大的時鐘差異；
同時消息傳輸時間是任意長的；
各節點對消息進行處理的時間也可能是任意長的。
這就造成無法判斷某個消息遲遲沒有被響應是哪裏出了問題（節點故障還是傳輸故障？）。
不幸地是，現實生活中的系統往往都是異步系統。
3.理解這一原理的一個不嚴謹的例子是：
三個人在不同房間，進行投票（投票結果是 0 或者 1）。三個人彼此可以通過電話進行溝通，但經常會有人時不時地睡着。比如某個時候，A 投票 0，B 投票 1，C 收到了兩人的投票，然後 C 睡着了。A 和 B 則永遠無法在有限時間內獲知最終的結果。如果可以重新投票，則類似情形每次在取得結果前發生：（
FLP 原理實際上說明對於允許節點失效情況下，純粹異步系統無法確保一致性在有限時間內完成。
這豈不是意味着研究一致性問題壓根沒有意義嗎？
先別這麼悲觀，學術界做研究，考慮的是數學和物理意義上最極端的情形，很多時候現實生活要美好的多（感謝這個世界如此魯棒！）。例如，上面例子中描述的最壞情形，總會發生的概率並沒有那麼大。工程實現上多試幾次，很大可能就成功了。
科學告訴你什麼是不可能的；工程則告訴你，付出一些代價，我可以把它變成可能。
這就是工程的魅力。
那麼，退一步講，在付出一些代價的情況下，我們能做到多少？
回答這一問題的是另一個很出名的原理：CAP 原理。
科學上告訴你去賭場賭博從概率上總會是輸錢的；工程則告訴你，如果你願意接受最終輸錢的結果，中間說不定偶爾能小贏幾筆呢！？
四、一致性問題
https://wohugb.github.io/blockchain_guide/distribute_system/problem/
1.定義：
在分佈式系統中，一致性(Consistency，早期也叫 Agreement)是指對於系統中的多個服務節點，給定一系列操作，在協議（往往通過某種共識算法）保障下，試圖使得它們對處理結果達成某種程度的一致。
如果分佈式系統能實現“一致”，對外就可以呈現爲一個功能正常的，且性能和穩定性都要好很多的“虛處理節點”。
注意：一致性並不代表結果正確與否，而是系統對外呈現的狀態一致與否，例如，所有節點都達成失敗狀態也是一種一致。
2.分佈式系統中一致性面臨的挑戰
在實際的計算機集羣系統中，存在如下的問題：
- 節點之間的網絡通訊是不可靠的，包括任意延遲和內容故障；
- 節點的處理可能是錯誤的，甚至節點自身隨時可能宕機；
- 同步調用會讓系統變得不具備可擴展性。
3.滿足一致性需要達到的條件
規範的說，理想的分佈式系統一致性應該滿足：
- 可終止性（Termination）：一致的結果在有限時間內能完成；
- 共識性（Consensus）：不同節點最終完成決策的結果應該相同；
- 合法性（Validity）：決策的結果必須是其它進程提出的提案。
第一點很容易理解，這是計算機系統可以被使用的前提。需要注意，在現實生活中這點並不是總能得到保障的，例如取款機有時候會是“服務中斷”狀態，電話有時候是“無法連通”的。
第二點看似容易，但是隱藏了一些潛在信息。算法考慮的是任意的情形，凡事一旦推廣到任意情形，就往往有一些驚人的結果。例如現在就剩一張票了，中關村和西單的電影院也分別剛確認過這張票的存在，然後兩個電影院同時來了一個顧客要買票，從各自“觀察”看來，自己的顧客都是第一個到的……怎麼能達成結果的共識呢？記住我們的唯一祕訣：核心在於需要把兩件事情進行排序，而且這個順序還得是大家都認可的。
第三點看似繞口，但是其實比較容易理解，即達成的結果必須是節點執行操作的結果。仍以賣票爲例，如果兩個影院各自賣出去一千張，那麼達成的結果就是還剩八千張，決不能認爲票售光了。
4.帶約束的一致性
做過分佈式系統的讀者應該能意識到，絕對理想的強一致性（Strong Consistency）代價很大。除非不發生任何故障，所有節點之間的通信無需任何時間，這個時候其實就等價於一臺機器了。實際上，越強的一致性要求往往意味着越弱的性能。
一般的，強一致性（Strong Consistency）主要包括下面兩類：
- 順序一致性（Sequential Consistency）：Leslie Lamport 1979 年經典論文《How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs》中提出，是一種比較強的約束，保證所有進程看到的 全局執行順序（total order）一致，並且每個進程看自身的執行（local order）跟實際發生順序一致。例如，某進程先執行 A，後執行 B，則實際得到的全局結果中就應該爲 A 在 B 前面，而不能反過來。同時所有其它進程在全局上也應該看到這個順序。順序一致性實際上限制了各進程內指令的偏序關係，但不在進程間按照物理時間進行全局排序。
- 線性一致性（Linearizability Consistency）：Maurice P. Herlihy 與 Jeannette M. Wing 在 1990 年經典論文《Linearizability: A Correctness Condition for Concurrent Objects》中共同提出，在順序一致性前提下加強了進程間的操作排序，形成唯一的全局順序（系統等價於是順序執行，所有進程看到的所有操作的序列順序都一致，並且跟實際發生順序一致），是很強的原子性保證。但是比較難實現，目前基本上要麼依賴於全局的時鐘或鎖，要麼通過一些複雜算法實現，性能往往不高。
強一致的系統往往比較難實現。很多時候，人們發現實際需求並沒有那麼強，可以適當放寬一致性要求，降低系統實現的難度。例如在一定約束下實現所謂最終一致性（Eventual Consistency），即總會存在一個時刻（而不是立刻），系統達到一致的狀態，這對於大部分的 Web 系統來說已經足夠了。這一類弱化的一致性，被籠統稱爲弱一致性（Weak Consistency）。
五、共識算法
1.定義
實際上，要保障系統滿足不同程度的一致性，往往需要通過共識算法來達成。
共識算法解決的是對某個提案（Proposal），大家達成一致意見的過程。提案的含義在分佈式系統中十分寬泛，如多個事件發生的順序、某個鍵對應的值、誰是領導……等等，可以認爲任何需要達成一致的信息都是一個提案。
注：實踐中，一致性的結果往往還需要客戶端的特殊支持，典型地通過訪問足夠多個服務節點來驗證確保獲取共識後結果。
2.問題挑戰
實際上，如果分佈式系統中各個節點都能保證以十分強大的性能（瞬間響應、高吞吐）無故障的運行，則實現共識過程並不複雜，簡單通過多播過程投票即可。
很可惜的是，現實中這樣“完美”的系統並不存在，如響應請求往往存在時延、網絡會發生中斷、節點會發生故障、甚至存在惡意節點故意要破壞系統。
一般地，把故障（不響應）的情況稱爲“非拜占庭錯誤”，惡意響應的情況稱爲“拜占庭錯誤”（對應節點爲拜占庭節點）。
3.常見算法
針對非拜占庭錯誤的情況，一般包括 Paxos、Raft 及其變種。
對於要能容忍拜占庭錯誤的情況，一般包括 PBFT 系列、PoW 系列算法等。從概率角度，PBFT 系列算法是確定的，一旦達成共識就不可逆轉；而 PoW 系列算法則是不確定的，隨着時間推移，被推翻的概率越來越小。