分散式系統特性與衡量標準

　　透明性：使用分散式系統的使用者並不關心繫統是怎麼實現的，也不關心讀到的資料來自哪個節點，對使用者而言，分散式系統的最高境界是使用者根本感知不到這是一個分散式系統

　　可擴充套件性：分散式系統的根本目標就是為了處理單個計算機無法處理的任務，當任務增加的時候，分散式系統的處理能力需要隨之增加。簡單來說，要比較方便的通過增加機器來應對資料量的增長，同時，當任務規模縮減的時候，可以撤掉一些多餘的機器，達到動態伸縮的效果

　　可用性與可靠性：一般來說，分散式系統是需要長時間甚至7*24小時提供服務的。可用性是指系統在各種情況對外提供服務的能力，簡單來說，可以通過不可用時間與正常服務時間的必知來衡量；而可靠性而是指計算結果正確、儲存的資料不丟失。

　　高效能：不管是單機還是分散式系統，大家都非常關注效能。不同的系統對效能的衡量指標是不同的，最常見的：高併發，單位時間內處理的任務越多越好；低延遲：每個任務的平均時間越少越好。這個其實跟作業系統CPU的排程策略很像

　　一致性：分散式系統為了提高可用性可靠性，一般會引入冗餘（複製集）。那麼如何保證這些節點上的狀態一致，這就是分散式系統不得不面對的一致性問題。一致性有很多等級，一致性越強，對使用者越友好，但會制約系統的可用性；一致性等級越低，使用者就需要相容資料不一致的情況，但系統的可用性、併發性很高很多。

元件、理論、協議

　　假設這是一個對外提供服務的大型分散式系統，使用者連線到系統，做一些操作，產生一些需要儲存的資料，那麼在這個過程中，會遇到哪些元件、理論與協議呢

用一個請求串起來

　　使用者使用Web、APP、SDK，通過HTTP、TCP連線到系統。在分散式系統中，為了高併發、高可用，一般都是多個節點提供相同的服務。那麼，第一個問題就是具體選擇哪個節點來提供服務，這個就是負載均衡（load balance）。負載均衡的思想很簡單，但使用非常廣泛，在分散式系統、大型網站的方方面面都有使用，或者說，只要涉及到多個節點提供同質的服務，就需要負載均衡。

　　通過負載均衡找到一個節點，接下來就是真正處理使用者的請求，請求有可能簡單，也有可能很複雜。簡單的請求，比如讀取資料，那麼很可能是有快取的，即分散式快取，如果快取沒有命中，那麼需要去資料庫拉取資料。對於複雜的請求，可能會呼叫到系統中其他的服務。

　　承上，假設服務A需要呼叫服務B的服務，首先兩個節點需要通訊，網路通訊都是建立在TCP/IP協議的基礎上，但是，每個應用都手寫socket是一件冗雜、低效的事情，因此需要應用層的封裝，因此有了HTTP、FTP等各種應用層協議。當系統愈加複雜，提供大量的http介面也是一件困難的事情。因此，有了更進一步的抽象，那就是RPC（remote produce call），是的遠端呼叫就跟本地過程呼叫一樣方便，遮蔽了網路通訊等諸多細節，增加新的介面也更加方便。

　　一個請求可能包含諸多操作，即在服務A上做一些操作，然後在服務B上做另一些操作。比如簡化版的網路購物，在訂單服務上發貨，在賬戶服務上扣款。這兩個操作需要保證原子性，要麼都成功，要麼都不操作。這就涉及到分散式事務的問題，分散式事務是從應用層面保證一致性：某種守恆關係。

　　上面說道一個請求包含多個操作，其實就是涉及到多個服務，分散式系統中有大量的服務，每個服務又是多個節點組成。那麼一個服務怎麼找到另一個服務（的某個節點呢）？通訊是需要地址的，怎麼獲取這個地址，最簡單的辦法就是配置檔案寫死，或者寫入到資料庫，但這些方法在節點資料巨大、節點動態增刪的時候都不大方便，這個時候就需要服務註冊與發現：提供服務的節點向一個協調中心註冊自己的地址，使用服務的節點去協調中心拉取地址。

　　從上可以看見，協調中心提供了中心化的服務：以一組節點提供類似單點的服務，使用非常廣泛，比如命令服務、分散式鎖。協調中心最出名的就是chubby，zookeeper。

　　回到使用者請求這個點，請求操作會產生一些資料、日誌，通常為資訊，其他一些系統可能會對這些訊息感興趣，比如個性化推薦、監控等，這裡就抽象出了兩個概念，訊息的生產者與消費者。那麼生產者怎麼講訊息傳送給消費者呢，RPC並不是一個很好的選擇，因為RPC肯定得指定訊息發給誰，但實際的情況是生產者並不清楚、也不關心誰會消費這個訊息，這個時候訊息佇列就出馬了。簡單來說，生產者只用往訊息佇列裡面發就行了，佇列會將訊息按主題（topic）分發給關注這個主題的消費者。訊息佇列起到了非同步處理、應用解耦的作用。

　　上面提到，使用者操作會產生一些資料，這些資料忠實記錄了使用者的操作習慣、喜好，是各行各業最寶貴的財富。比如各種推薦、廣告投放、自動識別。這就催生了分散式計算平臺，比如Hadoop，Storm等，用來處理這些海量的資料。

　　最後，使用者的操作完成之後，使用者的資料需要持久化，但資料量很大，大到按個節點無法儲存，那麼這個時候就需要分散式儲存：將資料進行劃分放在不同的節點上，同時，為了防止資料的丟失，每一份資料會儲存多分。傳統的關係型資料庫是單點儲存，為了在應用層透明的情況下分庫分表，會引用額外的代理層。而對於NoSql，一般天然支援分散式。

一個簡化的架構圖

　　下面用一個不大精確的架構圖，儘量還原分散式系統的組成部分（不過只能體現出技術，不好體現出理論）

?　

最後

分享一些系統的面試題，大家可以拿去刷一刷，準備面試漲薪。

請點贊後，戳這裡，免費獲取！

這些面試題相對應的技術點：

• JVM
• MySQL
• Mybatis
• MongoDB
• Redis
• Spring
• Spring boot
• Spring cloud
• Kafka
• RabbitMQ
• Nginx
• ......

大類就是：

• Java基礎
• 資料結構與演算法
• 併發程式設計
• 資料庫
• 設計模式
• 微服務
• 訊息中介軟體