每一個程序員，都渴望成為一名分布式系統架構師，MongoDB數據分布不均的解决方案

那些高大上的算法呢？

能瞬間閃回的容錯機制呢？

無縫熱昇級的功能呢？

問題到底出現在哪裏？

我們搭建的這套簡單的系統真的是我們日常談論的分布式系統嗎？

 2. 為什麼我們要搞分布式系統

---

為什麼要搞分布式系統？答案很簡單：形勢所迫！一套分布式系統往往是由於業務發展後采取的終極方案。

假如公司新開展了一項在線業務，而我們因此要為這套業務搭建開發一套業務系統。往往這時候，由於項目前景未知，又由於要快速上線進入市場做試錯，此時，我們可能會優先搞一套單體架構，先上線。

隨著業務的開展和運營，我們往往面臨的第一個問題是系統的崩潰和服務器的宕機。

這時候，大家就搞一套高可用架構來解决問題。把相同的項目部署在多臺機器上，一臺機器出問題了，直接換到另外一臺提供服務即可。

隨後，由於業務進一步的發展和壯大，此時，出現瓶頸的往往就是系統的響應時間了。響應時間的增加直接影響了用戶體驗，而這本身也反映了吞吐量出現了瓶頸。

對於這種問題，架構師們就會祭出集群大法好的思路來搞定。這時候，系統架構開始複雜了起來，因為別忘了，我們在保證負載均衡的同時，還需要保證服務的高可用。

到目前為止，貌似沒什麼問題了。我們通過高可用保證了系統的可靠性，通過負載均衡，分散了系統的壓力。

但是，以上這些方案都不是分布式，系統也不是分布式系統，依然是 Monoliths 這種被一些技術瘋子們嘲笑的笨重架構。

我們還需要分布式嗎？

上圖是某大廠的支付平臺一小部分架構圖。

從這張圖可以看出，業務發展到後面會有多麼複雜。面對如此複雜的業務，我們發現我們之前搞的那種集群怎麼也說不過去了。

這時候，就需要進行業務的拆分。

雖然業務拆分了，但是這些業務終究是要對外合作提供一個整體的服務的，這時候，才是真正需要分布式系統的時候了。我們需要一組在不同的服務器上相互協作的系統。

所以我們說，分布式系統是由於業務發展後的終極解决方案。最終，業務複雜到拆分的地步，那麼分布式系統就是天然的需求了。

在這裏，我們也可以解答下上節我們面臨的問題了。我們需要的不是簡單的直接把模塊分散部署的無意義分布式，不是簡單的模塊分解。我們需要的是系統在被迫搞成分布式的情况下依然能够：

1. 保持出色的性能

2. 擁有著無比可靠的可用性

3. 以及非常優秀的彈性

而為了保證以上這三個指標，就出現了分布式系統那繁雜艱深的技術棧。

 3. 分布式系統的技術棧

---

上面我們說了，分布式系統的出現完全是形式所迫，完全是業務發展導致的最終結果。而由於業務的拆分，我們又被迫會衍生出更多的分布式需求來，以及應對這些需求的技術：

• 因為業務拆分的多，業務對應的模塊之間就需要通信，為了保證通信的快速可靠，我們需要掌握分布式通信技術。

• 業務拆分的過多，每個模塊可能還需要搞集群，那麼多服務器資源，為了能够保證資源的精准分配，我們還需要考慮分布式資源管理和負載調度技術。

• 業務拆分之後，模塊與模塊之間又需要對很多共享數據做訪問，為了保證安全完整的數據狀態，我們也要用到分布式協調與同步技術。

• 到了業務拆分的階段，數據必然龐大，為了數據存儲的可靠，為了保證優秀的數據讀寫性能，我們需要分布式存儲技術。

• 業務如此複雜，為了公司的發展，業務能繼續擴大，就需要能更加精准的營銷和運營，我們還需要對數據進行實時、離線處理分析，此時，我們又得考慮分布式計算技術。

• 在業務拆分後，整體架構出現了巨變，不可能再用以前集群方式的思維去考慮高可用，那麼分布式的可靠性技術又要納入我們的掌握範疇。

  

  你看分布式系統的技術棧這麼多、這麼複雜對吧，別慌。

我寫這篇文章不是為了勸退你們的，我們要學習必須分步驟分主題的學習，對整體的分布式技術棧分而克之，逐步掌握。

 4. 如何學習分布式系統的技術棧

---

在分布式技術棧中我們可以看到，其實分布式技術是有分類的，我們可以根據不同的分類去掌握每種類別的分布式技術背後的概念和思想。無論分布式技術有多少實現，這些實現永遠都是以其所在分類的分布式技術原理作為核心底層來實現的。

同時呢，我們在學習當中，還必須理論聯系實際，根據我們的實際開發和架構需要學習。

而且，業務是逐步發展的，項目也不會一下就發展的特別龐大。這就給與了我們分步學習，逐步掌握的時間和機會。

 4.1 分布式通信

---

那具體到底如何做呢？

首先，分布式中的根基是什麼？就我自己的經曆而言，我認為是通信，最重要的其實分布式系統中那些模塊中的通信機制。

而通信機制該怎麼學習？我認為首先要了解我們可用的各通信機制的區別。其中尤為重要的是了解各通信機制的缺點。對，你沒看錯，就是缺點。

為什麼缺點最重要呢？因為架構師在架構的時候，一項尤為重要的工作就是做技術選型。而技術選型的目標很多時候的應用場景往往非常模糊，如果能了解到各選型的缺點，則對選型的結果是否准確就起到了極其重要的作用。

比如，我們現在想搞模塊間通信，那麼到底是用 RPC 還是用 MQ ？此時，我們知道 RPC 的缺點和 MQ 的缺點的話，就能很容易做出更准確的選型。

RPC 的缺點:

1. 不能搞流量削鋒

2. 不能廣播給多個模塊

3. 消息投遞沒有保證

4. 模塊和模塊之間沒法解耦

MQ 的缺點：

1. 不能保證延遲時間

2. 不適合搞强一致性的事務

3. 增加了系統的複雜度

4. 降低了系統的可用性

好了，知道了缺點，我們就很容易選型了。如果我們現在有個業務是實時扣費，我們肯定要搞 RPC，因為這是延遲敏感並且是需要强一致性。

如果我們現在有個業務是同時給會計系統和合作方發記賬請求的需求，那這時候我們就可能選用 MQ 通信了。

 4.2 分布式協調和同步

---

我們理解了分布式通信之後，下一步我認為最要學的是分布式協調和同步。

因為在現實裏，即使系統搞成分布式了，其實往往沒有特別大，分布式資源管理暫時可以先不考慮。分布式存儲也可能還在使用數據庫的主備或者 Sharding 方式在抗。而分布式計算的需求也可能沒有那麼緊急。

但是，一旦分布式系統中的全局狀態出問題了，那就是事故了。所以，理解分布式協調和同步，一定是很緊急也很重要的。

那協調和同步怎麼學呢？

我們要知道，我們所謂的協調數據訪問，同步數據訪問到底是在做什麼。其實協調數據訪問的本質就是去對數據訪問的請求做優先級排列，這就是協調數據訪問的本質。而如何定義優先級？根據什麼定義優先級？就是我們需要學習的東西。

至於同步，其實就是對數據訪問的保護。如何限制對數據的訪問？限制數據訪問的策略是什麼？就是同步的本質。

然後，如果我們理解了多線程的數據協調和同步，我們通過分布式和多線程的相同和區別，能更容易更快速的去把握好分布式協調的技術本質。

 4.3 分布式存儲

---

當理解了分布式協調和同步之後，我們就應該關注分布式存儲。因為業務的核心是數據，海量的數據最終還需要分布式存儲來解决安全可靠的持久化問題。

而分布式存儲最最重要的是理解什麼？不是存儲的各種實現，是分布式存儲的立身之本：CAP 理論。

我們通過對 CAP 理論的理解，去理解分布式存儲實現是如何實現對應的 CP 或者 AP 的，就會非常容易了。並且理解了 CAP，我們就能根據真實的業務需求，理解業務是需要 CP 還是 AP，然後就能根據這些，對分布式存儲做合適的選型了。

 4.4 分布式計算

---

當學習了分布式存儲，此時，我們就應該去學習分布式計算。因為分布式計算很可能會成為一個重要的運營需求。而分布式計算，就整體而言，一共就四種模式。任你千變萬化，都逃不掉這四種模式。

從計算方式上看，一共就兩種方法：

1. MR 方式（MapReduce）

2. Stream 方式

從處理過程來看，也只有兩種模式：

1. Actor 模式

總結

互聯網大廠比較喜歡的人才特點：對技術有熱情，强硬的技術基礎實力；主動，善於團隊協作，善於總結思考。無論是哪家公司，都很重視高並發高可用技術，重視基礎，所以千萬別小看任何知識。面試是一個雙向選擇的過程，不要抱著畏懼的心態去面試，不利於自己的發揮。同時看中的應該不止薪資，還要看你是不是真的喜歡這家公司，是不是能真的得到鍛煉。其實我寫了這麼多，只是我自己的總結，並不一定適用於所有人，相信經過一些面試，大家都會有這些感觸。

**另外想要面試題及答案的小夥伴請 點擊這裏自行領取，本人還整理收藏了2021年多家公司面試知識點以及各種技術點整理 **

下面有部分截圖希望能對大家有所幫助。