低下自己的心，準備起飛了-_-
分散式系統概要
昨天晚上看到了一本很有用的小冊子，大約60多頁，名字叫做Distributed systems for fun and profit，內容涉及了分散式系統的方方面面：有基本的分散式系統的概念，有複雜的分散式一致性協議，有關於分散式系統的擴充套件性，可用性，可靠性，高吞吐，低延遲的討論。不出意外的話，準備有兩天的時間，把它的全部內容付諸於這篇部落格中。事實上，只要在搜尋隨便輸入那本書的名字，就可以再網上搜索出一大堆的個人理解，但是最喜歡第一手資料的我還是喜歡讀原文，喜歡寫總結。
宣告： 不喜歡完整的翻譯原文，總感覺全部的翻譯之後總感覺啥都沒說。邊寫邊思考再邊總結，常常能獲得質的提升，但是這無法避免會出現由於個人知識水平或者理解能力的欠缺引起的疏漏或者錯誤，還請諒解。不變的一點是最權威的參考是論文，次權威的參考是原文。本文只希望能夠以個人這幾年來對分散式系統的淺薄認識能對原文進行一些Chinese型別的直觀理解，沉澱自己，方便他人。
總體概覽
全文分為五大章節，分別涵蓋了分散式系統的基本概念，分散式系統的一致性協議，分散式系統的時序性，副本的強一致性和副本的弱一致性，基本上各個章節都穿插了分散式系統的多維特徵之間的權衡：可靠性，可用性，故障容錯，一致性，低延遲，高吞吐。話不多說，開始緒論。
分散式系統程式設計本質上都是在處理兩個公理帶來的影響
- 訊息在系統中以光速傳播
- 獨立的事物，其故障的發生也是獨立的
這兩句話實際上陳述了分散式系統的基本事實：延遲無法避免，因為訊息傳輸的速度是有限的，雖然是光速，但依然會有latency（其實從網路的角度，不僅有傳輸時延，還有傳送時延）；故障的發生是一個常態事件，因為分散式系統的叢集規模很大，各種各樣型別的裝置都會可能由於掉電，老化，以及軟體層面的bug發生故障，這是一個常態事件，是無法避免的。
為了更好的理解上面的內容，我們來看兩個假設：(a) 假如訊息以無窮大的速度傳統，也就是沒有時延，這樣的話，我們就可以隨便採用基於consensus的強一致性的協議（例如paxos，raft等），只要一個請求能夠被大部分server響應，則成功。傳統意義上來說，強一致性協議的代價較大（目前paxos需要兩輪的RTT），極大影響系統可用性，而無時延假設恰恰使得我們的系統可用性有保證；(b) 假設系統永遠不會有故障，我們可以採用要求servers全響應語義的一致性協議（例如2PC），只有在所有的server必須全部響應後，才算做客戶端請求成功，然而實際系統中各式各樣的故障，使得這種要求很難滿足，可用性很難保證。其實上述兩個假設，恰好對應於CAP理論中的P和A，我們知道CAP無法全部滿足，但是對於(a)假設，我們可以構造滿足CP的系統；對於(b)假設，我們可以構造滿足CA的系統，關於CAP的細節，將會在後面的第二章分散式系統的一致性協議中具體闡述。
上述的兩個限制條件使得我們在分散式系統的設計中，必須去協調distance，latency以及consistence之間的關係，以設計出滿足現實需求的系統
各章節簡述
- 分散式系統基本概念 本節講述
- 分散式系統資料一致性
- 時序性
- 副本的強一致性
- 副本的弱一致性
分散式系統基本概念
什麼叫作分散式系統？它本質上是使用多機來解決單機的問題。
Distributed programming is the art of solving the same problem that you can solve on a single computer using multiple computers.
在Apache Spark的那篇論文的通用性中，我們說到分散式系統任何型別的計算任務本質上都可以歸結為兩個部分，而傳統的MapReduce語義恰好能夠完美匹配這兩個語義。
- Local Computation
- Exchange data among different nodes
同理，你不僅要問，對於一個系統來說，需要滿足哪種最基本的tasks？
- Storage
- Computation
仔細思考，確實如此。所有的系統本質上都是在完成兩種任務，資料儲存和資料轉換。例如資料庫中的資料是儲存，而查詢語言是計算，HDFS是純儲存，Spark是純計算。分散式系統的設計目標就是要使它從外面來看，更像是一臺機器，而不是多臺機器連線的組合。假如你有一臺magical machine，它有足夠多的資源，那麼你完全不需要一個分散式系統。但是事實上，一臺機器的資源總是有限的。在過去的時代，有不少企業一直在單機效能的道路上奔走，以求打造能處理更大任務的強單機系統，但是最後都宣告失敗，因為隨著單機效能越強，付出等量的代價帶來的收益比越小。分散式系統成功的歷史程序告訴我們，用大量廉價的機器打造的系統，可以獲得遠超過使用相同代價構造的單機系統。其實，從CPU的歷史程序與之有很多相似之處，過去的CPU一直在追求單核CPU超高的頻率，核數並不多（我記得2008年，很多cpu才2核心），但是頻率提升到4GHZ之後，發現再向上提升頻率，現有的電晶體的設計就很難滿足了，因此現在為了提升單機效能，總是以量取勝，雖然單核頻率並不高，但是核數多啊，包括目前的各種大型機的設計，動輒數萬個核心。