這樣系統(tǒng)的學(xué)習(xí)分布式，他日必成大器！

本文的緣起是回答知乎圓桌會議「分布式系統(tǒng)之美」的問題「如何系統(tǒng)性地學(xué)習(xí)分布式系統(tǒng)?」，后面稍微整理了一下，形成了這一篇文章（知乎 ID：kylin）。

前言

學(xué)習(xí)一個知識之前，我覺得比較好的方式是先理解它的來龍去脈：即這個知識產(chǎn)生的過程，它解決了什么問題，它是怎么樣解決的，還有它引入了哪些新的問題（沒有銀彈），這樣我們才能比較好的抓到它的脈絡(luò)和關(guān)鍵點，不會一開始就迷失在細節(jié)中。

所以，在學(xué)習(xí)分布式系統(tǒng)之前，我們需要解決的第一個問題是：分布式系統(tǒng)解決了什么問題？

分布式系統(tǒng)解決了什么問題？

第一個是單機性能瓶頸導(dǎo)致的成本問題，由于摩爾定律失效，廉價 PC機性能的瓶頸無法繼續(xù)突破，小型機和大型機能提高更高的單機性能，但是成本太大高，一般的公司很難承受；

第二個是用戶量和數(shù)據(jù)量爆炸性的增大導(dǎo)致的成本問題，進入互聯(lián)網(wǎng)時代，用戶量爆炸性的增大，用戶產(chǎn)生的數(shù)據(jù)量也在爆炸性的增大，但是單個用戶或者單條數(shù)據(jù)的價值其實比軟件時代（比如銀行用戶）的價值是只低不高，所以必須尋找更經(jīng)濟的方案；

第三個是業(yè)務(wù)高可用的要求，對于互聯(lián)網(wǎng)的產(chǎn)品來說，都要求 7 * 24小時提供服務(wù)，無法容忍停止服務(wù)等故障，而要提供高可用的服務(wù)，唯一的方式就是增加冗余來完成，這樣就算單機系統(tǒng)可以支撐的服務(wù)，因為高可用的要求，也會變成一個分布式系統(tǒng)。

基于上面的三個原因可以看出，在互聯(lián)網(wǎng)時代，單機系統(tǒng)是無法解決成本和高可用問題的，但是這兩個問題對幾乎對所有的公司來說都是非常關(guān)鍵的問題，所以，從單機系統(tǒng)到分布式系統(tǒng)是無法避免的技術(shù)大潮流。

分布式系統(tǒng)是怎么來解決問題的？

那么，分布式系統(tǒng)是怎么來解決單機系統(tǒng)面臨的成本和高可用問題呢？

其實思路很簡單，就是將一些廉價的 PC 機通過網(wǎng)絡(luò)連接起來，共同完成工作，并且在系統(tǒng)中提供冗余來解決高可用的問題。

分布式系統(tǒng)引入了哪些新的問題？

我們來看分布式系統(tǒng)的定義：分布式系統(tǒng)是由一組通過網(wǎng)絡(luò)進行通信、為了完成共同的任務(wù)而協(xié)調(diào)工作的計算機節(jié)點組成的系統(tǒng)。在定義中，我們可用看出，分布式系統(tǒng)它通過多工作節(jié)點來解決單機系統(tǒng)面臨的成本和可用性問題，但是它引入了對分布式系統(tǒng)內(nèi)部工作節(jié)點的協(xié)調(diào)問題。

我們經(jīng)常說掌握一個知識需要理解它的前因后果，對于分布式系統(tǒng)來說，前因是「分布式系統(tǒng)解決了什么問題」，后果是「它是怎么做內(nèi)部工作節(jié)點的協(xié)調(diào)」，所以我們要解決的第二個問題是：分布式系統(tǒng)是怎么做內(nèi)部工作節(jié)點協(xié)調(diào)的？

分布式計算引入了哪些新的問題？

先從簡單的情況入手，對于分布式計算（無狀態(tài)）的情況，系統(tǒng)內(nèi)部的協(xié)調(diào)需要做哪些工作：

1、怎么樣找到服務(wù)？

在分布式系統(tǒng)內(nèi)部，會有不同的服務(wù)（角色），服務(wù) A 怎么找到服務(wù) B 是需要解決的問題，一般來說服務(wù)注冊與發(fā)現(xiàn)機制是常用的思路，所以可以了解一下服務(wù)注冊發(fā)現(xiàn)機制實現(xiàn)原理，并且可以思考服務(wù)注冊發(fā)現(xiàn)是選擇做成 AP 還是 CP
系統(tǒng)更合理（嚴(yán)格按 CAP 理論說，我們目前使用的大部分系統(tǒng)很難滿足 C 或者 A 的，所以這里只是通常意義上的 AP 或者 CP）；

2、怎么樣找到實例？

找到服務(wù)后，當(dāng)前的請求應(yīng)該選擇發(fā)往服務(wù)的哪一個實例呢？一般來說，如果同一個服務(wù)的實例都是完全對等的（無狀態(tài)），那么按負載均衡策略來處理就足夠（輪詢、權(quán)重、hash、一致性hash，fair等各種策略的適用場景）；如果同一個服務(wù)的實例不是對等的（有狀態(tài)），那么需要通過路由服務(wù)（元數(shù)據(jù)服務(wù)等）先確定當(dāng)前要訪問的請求數(shù)據(jù)做哪一個實例上，然后再進行訪問。

3、怎么樣避免雪崩？

系統(tǒng)雪崩是指故障的由于正反饋循序?qū)е虏粩鄶U大規(guī)則的故障。一次雪崩通常是由于整個系統(tǒng)中一個很小的部分出現(xiàn)故障于引發(fā)，進而導(dǎo)致系統(tǒng)其它部分也出現(xiàn)故障。比如系統(tǒng)中某一個服務(wù)的一個實例出現(xiàn)故障，導(dǎo)致負載均衡將該實例摘除而引起其它實例負載升高，最終導(dǎo)致該服務(wù)的所有實例像多米諾骨牌一樣一個一個全部出現(xiàn)故障。

避免雪崩總體的策略比較簡單，只要是兩個思路，一個是快速失敗和降級機制（熔斷、降級、限流等），通過快速減少系統(tǒng)負載來避免雪崩的發(fā)生；另一個為彈性擴容機制，通過快速增加系統(tǒng)的服務(wù)能力來避免雪崩的發(fā)生。這個根據(jù)不同的場景可以做不同的選擇，或者兩個策略都使用。

一般來說，快速失敗會導(dǎo)致部分的請求失敗，如果分布式系統(tǒng)內(nèi)部對一致性要求很高的話，快速失敗會帶來系統(tǒng)數(shù)據(jù)不一致的問題，彈性擴容會是一個比較好的選擇，但是彈性擴容的實現(xiàn)成本和響應(yīng)時間比快速失敗要大得多。

4、怎么樣監(jiān)控告警？

對于一個分布式系統(tǒng)，如果我們不能很清楚地了解內(nèi)部的狀態(tài)，那么高可用是沒有辦法完全保障的，所以對分布式系統(tǒng)的監(jiān)控（比如接口的時延和可用性等信息），分布式追蹤 Trace，模擬故障的混沌工程，以及相關(guān)的告警等機制是一定要完善的；

分布式存儲引入了哪些新的問題？

接下來我們再來看分布式存儲（有狀態(tài)）的內(nèi)部的協(xié)調(diào)是怎么做的，同時，前面介紹的分布式計算的協(xié)調(diào)方式在分布式存儲中同樣適用，就不再重復(fù)了：

1、分布式系統(tǒng)的理論與衡權(quán)

ACID、BASE 和 CAP 理論，了解這三個主題，推薦這一篇文章以及文章后面相關(guān)的參考文獻：
英文版本：https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-
changed/ 中文版本：https://www.infoq.cn/article/cap-twelve-years-later-how-the-
rules-have-changed/

2、怎么樣做數(shù)據(jù)分片？

單機的存儲能力是不可能存儲所有的數(shù)據(jù)的，所以需要解決怎么將數(shù)據(jù)按一定的規(guī)則分別存儲到不同的機器上，目前使用比較多的方案為：Hash、Consistent
Hash 和 Range Based 分片策略，可以了解一下它們的優(yōu)缺點和各自的應(yīng)用場景；

3、怎么樣做數(shù)據(jù)復(fù)制？

為什么滿足系統(tǒng)的高可用要求，需要對數(shù)據(jù)做冗余處理，目前的方案主要為：中心化方案（主從復(fù)制、一致性協(xié)議比如 Raft 和 Paxos 等）和
去中心化的方案（Quorum 和 Vector
Clock）了解一下它們的優(yōu)缺點和各自的應(yīng)用場景，以及對系統(tǒng)外部表現(xiàn)出來的數(shù)據(jù)一致性級別（線性一致性、順序一致性、最終一致性等）；

4、怎么樣做分布式事務(wù)？

對于分布式系統(tǒng)來說，要實現(xiàn)事務(wù)，首先需要有對并發(fā)事務(wù)進行排序的能力，這樣在事務(wù)沖突的時候，確認哪個事務(wù)提供成功，哪個事務(wù)提交失敗。對于單機系統(tǒng)來說這個完全不是問題，簡單通過時間戳加序號的方式就可以實現(xiàn)，但是對于分布式系統(tǒng)來說，系統(tǒng)中機器的時間不能完全同步，并且單臺機器序號也沒用全局意義，按上面的方式說行不通的。不過整個系統(tǒng)選一臺機器按單機的模式生產(chǎn)事務(wù)
ID 是可以的，同城多中心和短距離的異地多中心都沒有問題，不過想做成全球分布式系統(tǒng)的話，那么每一次事務(wù)都要去一個節(jié)點去獲取事務(wù) ID
的成本太高（比如中國杭州到美國東部的 RTT 為 200 + ms ），Google 的 Spanner 是通過 GPS 和原子鐘實現(xiàn) TrueTime
API 來解決這個問題從而實現(xiàn)全球分布式數(shù)據(jù)庫的。

有了事務(wù) ID 后，通過 2PC 或者 3PC 協(xié)議來實現(xiàn)分布式事務(wù)的原子性，其他部分和單機事務(wù)差別不大，就不再細說來。

進階學(xué)習(xí)階段

到這里，對分布式系統(tǒng)脈絡(luò)上有了基本的概念，接下來開始進入細節(jié)學(xué)習(xí)階段，這也是非常幸苦的階段，對于分布式系統(tǒng)的理解深入與否，對細節(jié)的深入度是很重要的評價指標(biāo)，畢竟魔鬼在細節(jié)。這里可以往兩個方面進行系統(tǒng)的學(xué)習(xí)：

1、從實踐出發(fā)

研究目前比較常用的分布式系統(tǒng)的設(shè)計，HDFS 或者 GFS（分布式文件系統(tǒng)）、Kafka 和 Pulsar（分布式消息隊列），Redis Cluster 和
Codis（分布式緩存），MySQL 的分庫分表（傳統(tǒng)關(guān)系型數(shù)據(jù)庫的分布式方案），MongoDB 的 Replica Set 和
Sharing機制集以及去中心化的 Cassandra（NoSQL數(shù)據(jù)庫），中心化的 TiDB 和去中心化的
CockroachDB（NewSQL），以及一些微服務(wù)框架等；

2、從理論出發(fā)

從理論出發(fā)，研究分布式相關(guān)的論文，這里推薦一本書「Designing Data-Intensive
Applications」（中文版本：數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計），先整體看書，對比較感興趣的章節(jié)，再讀一讀該章節(jié)中涉及到的相關(guān)參考文獻。

總結(jié)

本文從分布式系統(tǒng)解決的問題開始，再討論它是怎么樣來解決問題的，最后討論了它引入了哪些新的問題，并且討論這些新問題的解決辦法，這個就是分布式系統(tǒng)大概的知識脈絡(luò)。掌握這個知識脈絡(luò)后，那么就可以從實踐和理論兩個角度結(jié)合起來深入細節(jié)研究分布式系統(tǒng)了。

參考

• 知乎 | 如何系統(tǒng)性的學(xué)習(xí)分布式系統(tǒng)

• Martin Kleppmann.Designing Data-Intensive Applications

• CAP Twelve Years Later: How the "Rules" Have Changed?