點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

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

前? 言

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

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

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

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

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

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

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

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

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

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

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

我們來看分布式系統(tǒng)的定義：分布式系統(tǒng)是由一組通過網(wǎng)絡進行通信、為了完成共同的任務而協(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. 怎么樣找到服務？

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

2. 怎么樣找到實例？

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

3. 怎么樣避免雪崩？

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

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

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

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)方式在分布式存儲中同樣適用，就不再重復了：

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)缺點和各自的應用場景；

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

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

4. 怎么樣做分布式事務？

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

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

進階學習階段

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

1. 從實踐出發(fā)

研究目前比較常用的分布式系統(tǒng)的設計，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），以及一些微服務框架等；

2. 從理論出發(fā)

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

總? 結(jié)

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

參考鏈接

https://www.zhihu.com/question/320812569/answer/1386491563

https://book.douban.com/subject/26197294/

https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

想知道更多？掃描下面的二維碼關(guān)注我

后臺回復"技術(shù)"，加入技術(shù)群

【精彩推薦】

• 超清晰的DNS入門指南

• 如何用ELK搭建TB級的日志系統(tǒng)

• 深度好文：Linux系統(tǒng)內(nèi)存知識

• 日志采集系統(tǒng)都用到哪些技術(shù)？

• 面試官：為什么HashMap的加載因子是0.75？

• 原創(chuàng)|OpenAPI標準規(guī)范

• 如此簡單| ES最全詳細使用教程

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解
  

點個贊+在看，少個 bug?????

總結(jié)

以上是生活随笔為你收集整理的睡前必读 | 如何系统性地学习分布式系统?的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。