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

前言

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

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

分布式系統解決了什么問題？

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

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

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

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

分布式系統是怎么來解決問題的？

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

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

分布式系統引入了哪些新的問題？

我們來看分布式系統的定義：分布式系統是由一組通過網絡進行通信、為了完成共同的任務而協調工作的計算機節點組成的系統。在定義中，我們可用看出，分布式系統它通過多工作節點來解決單機系統面臨的成本和可用性問題，但是它引入了對分布式系統內部工作節點的協調問題。

我們經常說掌握一個知識需要理解它的前因后果，對于分布式系統來說，前因是「分布式系統解決了什么問題」，后果是「它是怎么做內部工作節點的協調」，所以我們要解決的第二個問題是：分布式系統是怎么做內部工作節點協調的？

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

先從簡單的情況入手，對于分布式計算（無狀態）的情況，系統內部的協調需要做哪些工作：

1、怎么樣找到服務？

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

2、怎么樣找到實例？

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

3、怎么樣避免雪崩？

系統雪崩是指故障的由于正反饋循序導致不斷擴大規則的故障。一次雪崩通常是由于整個系統中一個很小的部分出現故障于引發，進而導致系統其它部分也出現故障。比如系統中某一個服務的一個實例出現故障，導致負載均衡將該實例摘除而引起其它實例負載升高，最終導致該服務的所有實例像多米諾骨牌一樣一個一個全部出現故障。

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

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

4、怎么樣監控告警？

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

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

接下來我們再來看分布式存儲（有狀態）的內部的協調是怎么做的，同時，前面介紹的分布式計算的協調方式在分布式存儲中同樣適用，就不再重復了：

1、分布式系統的理論與衡權

ACID、BASE 和 CAP 理論，了解這三個主題，推薦這一篇文章以及文章后面相關的參考文獻：
英文版本：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、怎么樣做數據分片？

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

3、怎么樣做數據復制？

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

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

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

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

進階學習階段

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

1、從實踐出發

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

2、從理論出發

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

總結

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

參考

• 知乎 | 如何系統性的學習分布式系統

• Martin Kleppmann.Designing Data-Intensive Applications

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