適合分佈式系統工程師的分佈式系統理論

時間 2019-11-16

原文原文鏈接

適合分佈式系統工程師的分佈式系統理論

Gwen Shapira曾在Cloudera作工程師，如今宣傳Kafka，他在Twitter問了如下問題，使我有所思考。web

我想在分佈式理論上有所提高。應該從哪開始？有推薦的書？
— Gwen (Chen) Shapira (@gwenshap) August 7, 2014

我第一反應是「能夠看：FLP論文、paxos論文、Byzantine將軍論文」。我推薦的主要閱讀材料，若是你貿然去讀，你至少要閱讀6個月纔會有感受。由此可知，推薦一噸的理論論文讓你閱讀，這是瞭解分佈式系統的錯誤的方式（除非你在讀博士）。論文通常是深奧、複雜的，並且須要一系列學習和豐富的經驗才能感受到其貢獻、才能把其放到對應的場景(以理解和應用)。算法

工程師瞭解分佈式理論有什麼好處？api

很不幸，幾乎沒有好的引導文章，來總結、提煉、場景化分佈式系統理論中的重要結論和想法; 特別是通俗易懂的引導文章更沒有。
考慮這樣的空白區域，讓我想問另外一個問題：安全

一個分佈式系統工程師應該瞭解什麼樣的分佈式系統理論？app

這種狀況下，瞭解一點點理論並非壞事。我平常工做是一個分佈式系統工程師，下面會給出我認爲適合個人基本概念們。
你認爲我缺失的請告知我!cors

準備

下面四個讀物解釋了構建分佈式系統會遇到的困難。這些讀物都勾勒了一些列抽象而非技術的困難，分佈式系統工程師必需要克服這些困難。這些讀物的後面章節有更詳細的研究。dom

Distributed Systems for Fun and Profit 是一本小書，它想覆蓋分佈式系統中的一些基本問題，包括時鐘所起的做用、不一樣策略的複製。異步

Notes on distributed systems for young bloods - 非理論，而是一個很好的實踐，以讓你落到實處。分佈式

A Note on Distributed Systems - 一個經典論文，關於爲何你不能僞裝全部遠程交互像本地對象同樣。

The fallacies of distributed computing 分佈式計算的8個錯誤的推論，以提醒系統設計者。

你應該知道安全和活力:

安全說的是永遠不會發生壞事。好比，不返回不一致的值是一種安全，同一時刻不會選出兩個主節點也是一種安全。
活力說的是好事情終究會發生。好比，對於每一個api調用，一個系統終究會返回一個結果，這是一種活力；保證一次寫磁盤最終總能結束，這是一種活力。

失敗和時鐘

分佈式系統工程師面對的許多困難能夠歸結爲如下兩個緣由:

進程可能_失敗_
There is no good way to tell that they have done so

進程間怎麼共用時鐘、什麼樣的失敗能夠檢測、什麼樣的算法和原語能夠被正確實現，這三者之間有很深的聯繫。通常狀況下，咱們假設不一樣節點絕對沒法共用時鐘(時刻值或流過了多少時間).

你應該知道:

失敗模型的層次：節點崩潰後關機 -> 節點崩潰後死機(通過無限長時間後才響應) -> 惡意節點 (不遵照約定的規則) 。各個層次間逐漸將限制放鬆，你應該知道這些限制.
兩個節點之間，沒有任何共用時鐘，你怎麼肯定一個節點上的一個事件和另外一個節點上的另外一個事件之間的前後順序. 這就要閱讀Lamport時鐘和更通常化的Vector時鐘, 也能夠閱讀Dynamo論文.
容許單節點失敗對實現正確的分佈式系統有多大的衝擊？(見下面FLP結論處)
時鐘的不一樣模型：同步、部分同部、異步
失敗檢測是一個基本問題，失敗檢測能夠平衡準確度和完成度(若是能檢測到失敗了，則能夠允許不那麼準確、沒徹底作完)，失敗檢測也能夠解決安全和活力間的衝突。把失敗檢測做爲理論來研究的論文是 Chandra and Toueg’s ‘Unreliable Failure Detectors for Reliable Distributed Systems’. 不過也有一些簡短的總結-我特別喜歡this random one from Stanford.

容錯致使的基本矛盾

一個系統容忍一些錯誤而沒有降級必須能當成就像這些錯誤沒有發生過同樣。這意味着系統的一部分要冗餘地工做(一樣的功能部署多個節點)，冗餘是絕對必要的，冗餘通常會帶來性能和資源的消耗。這就是給一個系統添加冗餘的基本矛盾。

你應該知道：

確保串行單複製的多數派技術. 見 Skeen’s original paper, 不過或許更好的是 Wikipedia條目).

(多數派中有一個是主節點,其他爲從節點，以主節點接收到的寫請求序列爲準[即串行]，主節點單方面的要求從節點們接受主節點的寫請求序列[從節點不得反抗、不得有異議：從節點是誠實的非惡意的、遵照全局規則的、非拜占庭的])

兩步提交、三步提交、Paxos, 以及爲何他們不一樣於容錯.
最終一致性、其餘技術以對系統行爲作更弱的保證爲代價來設法避開此矛盾 . 能夠看 Dynamo 論文 , 不過必需要讀 Pat Helland的論文經典 Life Beyond Transactions .

基本原語

在分佈式系統中，不多有約定的基本構建塊，更多的是處於造成中的基本構建塊。你應該知道下面的問題是什麼，而且從哪能找到他們的解決方案：

主節點選舉 (例如 Bully 算法)
一致快照 (好比這個來自 Chandy and Lamport的經典論文 )
一致性 (見上面 2PC 、 Paxos 處)
分佈式狀態機複製 (看Wikipedia 就行, Lampson的論文是權威可是太枯燥了).
廣播 - 同時發送消息給集羣
- 原子廣播 - 你能發送消息給一集羣，使得要麼集羣中的全部節點都收到了這條信息、要麼集羣中所有節點都沒收到此消息?(這就是原子廣播)

*   Gossip ([經典論文](http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-89-1_Epidemic_Algorithms_for_Replicated_Database_Maintenance.pdf))
    
*   [因果廣播](https://www.cs.cornell.edu/courses/cs614/2003sp/papers/BSS91.pdf) (也能夠看看 [Birman](https://www.cs.rice.edu/~alc/comp520/papers/Cheriton_Skeen.pdf)和[forth](https://www.cs.princeton.edu/courses/archive/fall07/cos518/papers/catocs-limits-response.pdf) ).

鏈式複製 (將節點們放進一個虛擬鏈表中，從而能夠乾淨的確保寫請求的一致性和順序 ).
- 原始論文
- 對負載中讀請求佔絕大多數的一系列改良
- @slfritchie給出的一個經驗報告

基礎結論

有些事實只須要主觀理解(不須要關注證實).

若是節點間可能丟失消息[:P]，那麼你不可能既實現一致性存儲[:C] 又響應全部時刻的請求[:A]. 這就是 CAP理論.
在一個異步系統中，一致性不可能以這樣一個途徑實現：既a) 老是正確的；又b) 老是能結束即便只有一個節點可能以崩潰-*中止失敗 (FLP結論). 在看證實以前，看下我以簡明的方式解釋FLP結論的論文 Papers We Love SF talk . _建議: 沒有理解證實的須要_.

(一個異步系統中，假設節點崩潰後中止而不是奔潰後又恢復；一、要確保結果老是正確的，二、每次寫請求可以在有限時間內返回結果。這兩點無法同時知足：這就是FLP結論)