大咖說 | 胡志琳：分散式系統概述
對話 | 大咖
本期參與交流的技術大咖是：胡志琳
胡志琳，資深系統研發，清華大學直博，曾系統設計並實現某重點軍工專案的關鍵裝置，曾就職於滴滴出行等知名網際網路公司。
熱衷於區塊鏈系統的理論研究和工程實現，熟練掌握Bitcoin、Ethereum和EOS等區塊鏈技術。
主要負責分散式系統共識演算法的分析、設計與研發，以及密碼學和零知識證明等在實際業務中應用落地。
瞭解分散式系統，讀這一遍文章就足夠了。
1、分散式系統概述
分散式系統是由一組通過網路進行通訊、為了完成共同任務而協調工作的大量計算機節點組成的系統。單個節點的故障（程序crash、斷電、磁碟損壞）是個小概率事件，但整個系統的故障率會隨節點的增加而指數級增加，網路通訊也可能出現斷網、高延遲的情況。在這種一定會出現的“異常”情況下，分散式系統還是需要繼續穩定的對外提供服務，即需要較強的容錯性。
分散式系統需要大量機器協作，面臨諸多的挑戰：
第一，異構的機器與網路：分散式系統中的機器，配置不一樣，其上執行的服務也可能由不同的語言、架構實現，因此處理能力也不一樣；節點間通過網路連線，而不同網路運營商提供的網路的頻寬、延時、丟包率又不一樣。
第二，普遍的節點故障：雖然單個節點的故障概率較低，但節點數目達到一定規模，出故障的概率就變高了。分散式系統需要保證故障發生的時候，系統仍然是可用的，這就需要監控節點的狀態，在節點故障的情況下將該節點負責的計算、儲存任務轉移到其他節點。
第三，不可靠的網路：節點間通過網路通訊，而網路是不可靠的。可能的網路問題包括：網路分割、延時、丟包、亂序。
總而言之，分散式的挑戰來自不確定性，不確定計算機什麼時候crash、斷電，不確定磁碟什麼時候損壞，不確定每次網路通訊要延遲多久，也不確定通訊對端是否處理了傳送的訊息。而分散式的規模放大了這個不確定性，所以有諸多的分散式理論、協議來保證在這種不確定性的情況下，系統還能繼續正常工作。
2、分散式系統理論
基本可行性原理 FLP、CAP
基本共識演算法 Paxos、BFT、Zyzzyva、Quorum
FLP不可能原理：在網路可靠，存在節點失效（即便便只有一個）的最小化非同步模型系統中，不存在一個可以解決一致性問題的確定性演算法。
CAP不可能原理：分散式計算系統不可能同時確保一致性（Consistency）、可用性（Availablity）和分割槽容忍性（Partition），設計中往往需要弱化對某個特性的保證。
共識的基本定義：
系統n個節點，其中最多有f個崩潰，最少有n-f個節點是好的。節點i從vi開始，所有節點必須從全部輸入值中選擇一個值作為決策值，並且滿足下面的條件：
1、一致性，所有好節點的決策值必須相同；
2、有效性，選擇出的決策值必須是某個節點的輸入值；
3、可終止性，所有好節點在有限時間內結束決策過程；
共識的不可能性：
分散式系統理理論——FLP
對於非同步系統，節點崩潰錯誤是非常致命的，哪怕只有一個節點崩潰也不可能達成共識。即非同步系統下不存在確定性的容錯共識演算法，即使對於布林型輸入值也如此。
相關引理和定理
1、如果f>=1，至少存在一組輸入值V，使得相應的初始配置C0是二價的。
2、如果一個系統是在一個二價的配置中，這個系統必須在有限的時間內達到一個關鍵配置，否則這個系統就永遠不不能達成共識。
3、如果一個配置樹包含一個關鍵配置，單個節點的崩潰必然會導致一個二價葉子節點，也就是說單個節點崩潰阻礙了了演算法達成一致。
相關定理
當f>0時，不存在一個確定的演算法總能在非同步模型下達成共識。
分散式系統理理論——CAP
CAP 原理最早由 Eric Brewer 在 2000 年，ACM 組織的一個研討會上提出猜想，後來 2002年年Lynch 等人進行了證明。分散式計算系統不可能同時確保一致性（Consistency）、可用性（Availability）和分割槽容忍性（Partition），設計中往往需要弱化對某個特性的保證。
一致性（Consistency）：任何操作應該都是原子的，發生在後面的事件能看到前面事件發生導致的結果，注意這里指的是強一致性；
可用性（Availability）：在有限時間內，任何非失敗節點都能應答請求；
分割槽容忍性（Partition）：網路可能發生分割槽，即節點之間通訊不不可保障。
分散式系統演算法——Paxos
相關引理
1、客戶端傳送一個提案(t,c)，如果提案被儲存在過半數伺服器上，則稱此提案被選中；如果已經存在一個提案被選中，則後續每一個提案(t',c')=(t,c)將始終成立；
2、如果一個命令c被某些伺服器器執行，那麼所有的伺服器最終將執行命令c；
相關歷史
1988-1996，萌芽期，開端的兩片論文被提出；
1996-2007，花團簇錦發展，提升Paxos效能，符合不同應用的需要；
2006-， 碩果累累，配置管理、資料庫備份，例如：Chubby\ZppKeeper等；
分散式系統演算法——BFT
一個可能呈現任意行為的節點稱為拜占庭，任意行為意味著“所有能想象到的事情”。
在一個存在拜占庭節點的系統中達成共識，稱為拜占庭協定。如果一個演算法可以在存在f個拜占庭節點的情況下正確工作，則稱該演算法為f-可適用。
拜占庭有效性
1、任何輸入有效性；2、正確輸入有效性；3、全部相同有效性；4、中值有效性；
拜占庭相關定理
若一個有n個節點的網路中存在f>=n/3個拜占庭節點，則該網路不能達成拜占庭協定。
拜占庭相關歷史
1980，EIG演算法複雜度和節點數量呈指數關係；其他的拜占庭演算法，國王演算法、皇后演算法，這些演算法要麼複雜度高，要麼容忍錯誤少。
PBFT是Practical Byzantine Fault Tolerance的縮寫，意為實用拜占庭容錯演算法。該演算法是Miguel Castro (卡斯特羅)和Barbara Liskov（利斯科夫）在1999年提出來的，解決了原始拜占庭容錯演算法效率不高的問題，將演算法複雜度由指數級降低到多項式級，使得拜占庭容錯演算法在實際系統應用中變得可行。
其他的共識演算法：
Zyzzyva，設計思想是在好的節點上快速運行，在遇到錯誤的時候慢下來修復。
Quorum，引入網格仲裁系統、B-網格、f-掩蓋網格仲裁和不透明仲裁系統。
多演算法效能比較：
1、POW，比特幣的交易輸出現狀是7筆每秒，能支援上萬個節點。
2，PBFT的交易輸出是1000筆每秒量級的，但是不可擴充套件，超過64個節點基本認為不可用。
3，改進的BFT演算法Zyzzyva的輸出是10k筆每秒量級的，這個演算法是可擴充套件的。與PBFT相比，它對惡意節點數量更敏感，惡意節點多的時候延遲會比PBFT高。
比特幣的安全假設是惡意節點的算力少於全網一半，PBFT和Zyzzyva是惡意節點數量少於1/3，而實際上在惡意節點增加的情況下，Zyzzyva的延遲會很高。
參考文獻：
1、什麼是分散式系統，如何學習分散式系統 https://www.cnblogs.com/xybaby/p/7787034.html