文章目錄

• • 分布式
  • • 分布式概述
    • • 分布式
      • 集群
      • 微服務
      • 多線程
      • 高并發
    • 分布式系統設計理念
    • • 分布式系統的目標與要素
      • 分布式系統設計兩大思路：中心化和去中心化
      • 分布式與集群的區別是什么？
    • CAP定理
  • CAP定理的證明
  • • BASE理論
    • • BASE理論的核心思想
      • BASE理論三要素
      • • 1. 基本可用
        • 2. 軟狀態
        • 3. 最終一致性

分布式

分布式概述

分布式

分布式（distributed）是為了解決單個物理服務器容量和性能瓶頸問題而采用的優化手段，將一個業務拆分成不同的子業務，分布在不同的機器上執行。服務之間通過遠程調用協同工作，對外提供服務。

該領域需要解決的問題極多，在不同的技術層面上，又包括：分布式緩存、分布式數據庫、分布式計算、分布式文件系統等，一些技術如MQ、Redis、zookeeper等都跟分布式有關。

從理念上講，分布式的實現有兩種形式：

水平擴展：當一臺機器扛不住流量時，就通過添加機器的方式，將流量平分到所有服務器上，所有機器都可以提供 相同的服務；

垂直拆分：前端有多種查詢需求時，一臺機器扛不住，可以將不同的業務需求分發到不同的機器上，比如A機器處理余票查詢的請求，B機器處理支付的請求。

集群

集群（cluster）是指在多臺不同的服務器中部署相同應用或服務模塊，構成一個集群，通過負載均衡設備對外提供服務。

兩個特點

可擴展性：集群中的服務節點，可以動態的添加機器，從而增加集群的處理能力。

高可用性：如果集群某個節點發生故障，這臺節點上面運行的服務，可以被其他服務節點接管，從而增強集群的高可用性。

兩大能力

負載均衡：負載均衡能把任務比較均衡地分布到集群環境下的計算和網絡資源。

集群容錯：當我們的系統中用到集群環境，因為各種原因在集群調用失敗時，集群容錯起到關鍵性的作用。

微服務

微服務就是很小的服務，小到一個服務只對應一個單一的功能，只做一件事。這個服務可以單獨部署運行，服務之間通過遠程調用協同工作，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責它的整個生命周期。

多線程

多線程（multi-thread）：多線程是指程序中包含多個執行流，即在一個程序中可以同時運行多個不同的線程來執行不同的任務。多線程是為了提高CPU的利用率。

高并發

高并發（High Concurrency）是一種系統運行過程中發生了一種“短時間內遇到大量請求”的情況，高并發對應的是訪問請求，多線程是解決高并發的方法之一，高并發還可以通過分布式，集群，算法優化，數據庫優化等方法解決。

分布式系統設計理念

分布式系統的目標與要素

分布式系統的目標是提升系統的整體性能和吞吐量另外還要盡量保證分布式系統的容錯性（假如增加10臺服務器才達到單機運行效果2倍左右的性能，那么這個分布式系統就根本沒有存在的意義）。

即使采用了分布式系統，我們也要盡力運用并發編程、高性能網絡框架等等手段提升單機上的程序性能。

分布式系統設計兩大思路：中心化和去中心化

中心化設計

• 兩個角色： 中心化的設計思想很簡單，分布式集群中的節點機器按照角色分工，大體上分為兩種角色： “領導” 和 “干活的”
• 角色職責： “領導”通常負責分發任務并監督“干活的”，發現誰太閑了，就想發設法地給其安排新任務，確保沒有一個“干活的”能夠偷懶，如果“領導”發現某個“干活的”因為勞累過度而病倒了，則是不會考慮先嘗試“醫治”他的，而是一腳踢出去，然后把他的任務分給其他人。其中微服務架構 Kubernetes 就恰好采用了這一設計思路。
• 中心化設計的問題
• 中心化的設計存在的最大問題是“領導”的安危問題，如果“領導”出了問題，則群龍無首，整個集群就奔潰了。但我們難以同時安排兩個“領導”以避免單點問題。
• 中心化設計還存在另外一個潛在的問題，既“領導”的能力問題：可以領導10個人高效工作并不意味著可以領導100個人高效工作，所以如果系統設計和實現得不好，問題就會卡在“領導”身上。
• 領導安危問題的解決辦法： 大多數中心化系統都采用了主備兩個“領導”的設計方案，可以是熱備或者冷備，也可以是自動切換或者手動切換，而且越來越多的新系統都開始具備自動選舉切換“領導”的能力，以提升系統的可用性。

去中心化設計

• 眾生地位平等： 在去中心化的設計里，通常沒有“領導”和“干活的”這兩種角色的區分，大家的角色都是一樣的，地位是平等的，全球互聯網就是一個典型的去中心化的分布式系統，聯網的任意節點設備宕機，都只會影響很小范圍的功能。
• “去中心化”不是不要中心，而是由節點來自由選擇中心。 （集群的成員會自發的舉行“會議”選舉新的“領導”主持工作。最典型的案例就是ZooKeeper及Go語言實現的Etcd）
• 去中心化設計的問題： 去中心化設計里最難解決的一個問題是 “腦裂”問題 ，這種情況的發生概率很低，但影響很大。腦裂指一個集群由于網絡的故障，被分為至少兩個彼此無法通信的單獨集群，此時如果兩個集群都各自工作，則可能會產生嚴重的數據沖突和錯誤。一般的設計思路是，當集群判斷發生了腦裂問題時，規模較小的集群就“自殺”或者拒絕服務。

分布式與集群的區別是什么？

• 分布式： 一個業務分拆多個子業務，部署在不同的服務器上
• 集群： 同一個業務，部署在多個服務器上。比如之前做電商網站搭的redis集群以及solr集群都是屬于將redis服務器提供的緩存服務以及solr服務器提供的搜索服務部署在多個服務器上以提高系統性能、并發量解決海量存儲問題。

CAP定理

在理論計算機科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer’s theorem），它指出對于一個分布式計算系統來說，不可能同時滿足以下三點：

選項描述

Consistency（一致性）	指數據在多個副本之間能夠保持一致的特性（嚴格的一致性）
Availability（可用性）	指系統提供的服務必須一直處于可用的狀態，每次請求都能獲取到非錯的響應（不保證獲取的數據為最新數據）
Partition tolerance（分區容錯性）	分布式系統在遇到任何網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務，除非整個網絡環境都發生了故障

Spring Cloud在CAP法則上主要滿足的是A和P法則，Dubbo和Zookeeper在CAP法則主要滿足的是C和P法則

CAP僅適用于原子讀寫的NOSQL場景中，并不適合數據庫系統。現在的分布式系統具有更多特性比如擴展性、可用性等等，在進行系統設計和開發時，我們不應該僅僅局限在CAP問題上。

注意：不是所謂的3選2（不要被網上大多數文章誤導了）

現實生活中，大部分人解釋這一定律時，常常簡單的表述為：“一致性、可用性、分區容忍性三者你只能同時達到其中兩個，不可能同時達到”。實際上這是一個非常具有誤導性質的說法，而且在CAP理論誕生12年之后，CAP之父也在2012年重寫了之前的論文。

當發生網絡分區的時候，如果我們要繼續服務，那么強一致性和可用性只能2選1。也就是說當網絡分區之后P是前提，決定了P之后才有C和A的選擇。也就是說分區容錯性（Partition tolerance）我們是必須要實現的。

CAP定理的證明

關于CAP這三個特性我們就介紹完了，接下來我們試著證明一下為什么CAP不能同時滿足。

為了簡化證明的過程，我們假設整個集群里只有兩個N1和N2兩個節點，如下圖：

N1和N2當中各自有一個應用程序AB和數據庫，當系統滿足一致性的時候，我們認為N1和N2數據庫中的數據保持一致。在滿足可用性的時候，我們認為無論用戶訪問N1還是N2，都可以獲得正確的結果，在滿足分區容錯性的時候，我們認為無論N1還是N2宕機或者是兩者的通信中斷，都不影響系統的運行。

我們假設一種極端情況，假設某個時刻N1和N2之間的網絡通信突然中斷了。如果系統滿足分區容錯性，那么顯然可以支持這種異常。問題是在此前提下，一致性和可用性是否可以做到不受影響呢？

我們做個假象實驗，如下圖，突然某一時刻N1和N2之間的關聯斷開：

有用戶向N1發送了請求更改了數據，將數據庫從V0更新成了V1。由于網絡斷開，所以N2數據庫依然是V0，如果這個時候有一個請求發給了N2，但是N2并沒有辦法可以直接給出最新的結果V1，這個時候該怎么辦呢？

這個時候無法兩種方法，一種是將錯就錯，將錯誤的V0數據返回給用戶。第二種是阻塞等待，等待網絡通信恢復，N2中的數據更新之后再返回給用戶。顯然前者犧牲了一致性，后者犧牲了可用性。

這個例子雖然簡單，但是說明的內容卻很重要。在分布式系統當中，CAP三個特性我們是無法同時滿足的，必然要舍棄一個。三者舍棄一個，顯然排列組合一共有三種可能。

BASE理論

BASE理論由eBay架構師Dan Pritchett提出，在2008年上被分表為論文，并且eBay給出了他們在實踐中總結的基于BASE理論的一套新的分布式事務解決方案。

BASE 是 Basically Available（基本可用） 、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性） 三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源于對大規模互聯網系統分布式實踐的總結，是基于CAP定理逐步演化而來的，它大大降低了我們對系統的要求。

BASE理論的核心思想

即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。也就是犧牲數據的一致性來滿足系統的高可用性，系統中一部分數據不可用或者不一致時，仍需要保持系統整體“主要可用”。

針對數據庫領域，BASE思想的主要實現是對業務數據進行拆分，讓不同的數據分布在不同的機器上，以提升系統的可用性，當前主要有以下兩種做法：

• 按功能劃分數據庫
• 分片（如開源的Mycat、Amoeba等）。

由于拆分后會涉及分布式事務問題，所以eBay在該BASE論文中提到了如何用最終一致性的思路來實現高性能的分布式事務。

BASE理論三要素

1. 基本可用

基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性。但是，這絕不等價于系統不可用。

比如：

• 響應時間上的損失：正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由于出現故障，查詢結果的響應時間增加了1~2秒
• 系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面

2. 軟狀態

軟狀態指允許系統中的數據存在中間狀態，并認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時

3. 最終一致性

最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

總結

以上是生活随笔為你收集整理的分布式——分布式面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。