摘要：什麼是分散式系統？為什麼要用分散式系統？分散式系統如何分佈？這些你知道嗎？
小引
分散式系統是一個古老而寬泛的話題，而近幾年因為 “大資料” 概念的興起，又煥發出了新的青春與活力。本文將會通過對如下幾個問題展開談一下分散式系統：
什麼是分散式系統？
為什麼要用分散式系統？
分散式系統設計推演
CAP定理是什麼？
分散式系統如何進行分佈？
分散式應用通常使用的架構型別哪些?
分散式系統的優缺點有哪些？
1. 什麼是分散式系統？
簡單的來說，一個分散式系統是一組計算機系統一起工作，在終端使用者看來，就像一臺計算機在工作一樣。
這組一起工作的計算機，擁有共享的狀態，他們同時執行，獨立機器的故障不會影響整個系統的正常執行。
我們現在舉個例子，傳統的資料庫是儲存在一臺機器的檔案系統上的。每當我們取出或者插入資訊的時候，我們直接和那臺機器進行互動。
那麼現在我們把這個傳統的資料庫設計成分散式資料庫。假設我們使用了三臺機器來構建這臺分散式資料庫，我們追求的結果是，在機器1上插入一條記錄，需要在機器3上可以返回那條記錄，當然了，機器1和2也要能夠返回這條記錄。
2. 為什麼要用分散式系統？
管理分散式系統是一個非常複雜的話題，裡面充滿了陷阱和地雷。部署維護和除錯分散式系統也是非常頭疼的一件事情，那為什麼還要去做呢？
分散式系統最大的好處就是能夠讓你橫向的擴充套件系統。
以前面提到的單一資料庫為例，能夠處理更多流量的唯一方式就是升級資料庫執行的硬體，這就是縱向擴充套件。
而縱向擴充套件的是有侷限性的。當到了一定程度以後，我們會發現即使最好的硬體，也不能夠滿足當前流量的需求。
橫向擴充套件是指通過增加更多的機器來提升整個系統的效能，而不是靠升級單臺計算機的硬體。
從價格上來說，橫向擴充套件相比縱向擴充套件更容易控制。
最根本的問題是縱向擴充套件有很強的侷限性，達到最新硬體的能力以後，還是無法滿足中等或者大型工作負載的技術要求。
橫向擴充套件則沒有這個限制，它沒有上限，每當效能下降的時候，你就需要增加一臺機器，這樣理論上講可以達到無限大的工作負載支援。
除此之外，在容錯和低延遲上也有很多優勢。容錯性是指你的分散式系統的某個節點出現錯誤以後，並不會導致整個系統的癱瘓。而單機系統出錯以後，可能會導致整個系統的崩潰。
低延遲是通過在不同的物理位置部署不同的機器，通過就近獲取的原則降低訪問的延遲時間。
上面討論了分散式系統的種種好處，但是我們必須要清楚設計和執行分散式系統並非易事。
3. 分散式系統設計推演
我們先講一個場景，我們現有的網路應用變得越來越流行，服務的人數也越來越多，導致我們的應用程式每秒收到的請求，遠遠超過能夠正常處理的數量。這會導致應用程式效能下降明顯，使用者也會注意到這一點。
那我們下面就來擴充套件一下我們的應用程式來滿足更高的要求。一般來說我們讀取資訊的頻率要遠遠超過插入或者修改的頻率。
下面我們使用主從複製策略來實現擴充套件系統。我們可以建立兩個新的資料庫伺服器，他們與主伺服器同步。使用者業務對這兩個新的資料庫只能讀取。每次當向主資料庫插入和修改資訊時，都會非同步的通知副本資料庫進行更新變化。
在這一步上我們已經有了三倍於原來系統讀取資料的效能支援。但是這裡有一個問題，在資料庫事務的設計當中，我們遵循ACID原則。但是在我們同時對其他兩個資料庫進行資料更新的時候，我們有一個時間視窗失去了一致性原則。如果在這個時間視窗內對兩個新的資料庫進行查詢，可能查不到資料。這個時候如果同步這三個資料庫的資料，就會影響寫操作的效能。
這是我們在設計分散式系統的時候，不得不承受的一些代價。
上面的主從複製策略解決了使用者讀取效能方面的需求，但是當資料量達到一定程度，一臺機子上無法存放的時候，我們需要擴充套件寫操作效能。要解決這樣的問題，我們可以使用分割槽技術。分割槽技術是指根據特定的演算法，比如使用者名稱a到z作為不同的分割槽，分別指向不同的資料庫寫入，每個寫入資料庫會有若干讀取的從資料庫進行同步提升讀取效能。
當然，這樣使得整套系統變得更加複雜。最重要的難點是分割槽演算法。你們試想一下，如果c開頭的使用者名稱比其他開頭的使用者名稱要多很多，這會導致c區的資料量非常龐大，相應地，對於c區的請求也會遠遠大於其他區。此時c區成為熱點。要避免熱點，需要對c區進行拆分。此時要進行共享資料就會變得非常昂貴，甚至可能導致停機。
如果一切都很理想，那我們就擁有了 n倍的寫入流量，n是分割槽的數目。
當然這裡也存在一個陷阱，我們進行資料分割槽以後，導致除了分割槽鍵以外的查詢都變得非常低效，尤其是對於sql語句如join查詢就變得非常之糟糕，導致一些複雜的查詢根本無法使用。
這裡有一個思考題:
如何選擇更好的分割槽策略演算法？
4. CAP定理是什麼？
這個定理是指一個分散式系統不能同時具有一致性，可用性和分割槽容忍性。
一致性Consistency: 依次讀寫的是什麼就是什麼。
可用性Availability: 整個系統不會崩潰, 每個非故障節點總會有一個相應。
分割槽容忍Partition tolerant: 儘管有分割槽，系統仍能繼續執行並保持其一致性和可用性。
對於任何分散式系統來說，分割槽容忍是一個給定的條件，如果沒有這一點，就不可能做到一致性和可用性。試想如果兩個節點連結斷掉了，他們如何能夠做到既可用又一致?
最後你只能選擇在網路分割槽情況下，你的系統要麼強一致，要麼高可用。
實踐表明大多數應用程式更看重可用性。這個考量的主要原因是在不得不同步機器裡實現強於一致性是時，網路延遲會成為一個問題。
這類因素使得應用程式通常會選擇提供高可用性的解決方案。
此時採用的是最弱的一致性模型來解決的，這種模型保證瞭如果沒有對某個專案進行新的更新，最終對該專案的所有訪問都會返回最新的值。
這些系統提供了BASE屬性，這是相對於傳統資料庫的ACID來講的。 也就是( Basically available)基本上是可用的，系統總會返回一個響應。
( Soft state)軟狀態, 系統可以隨著時間的推移而變化，甚至在沒有輸入的情況下也可以變化, 如保持最終的一致性的同步。
( Eventual consistency)最終的一致性, 在沒有輸入的情況下，資料遲早會傳播到每一個節點上，從而變得一致。
追求高可用的分散式資料庫例子有Cassandra；看重強一致性的資料庫，有HBase， Redis， Zookeeper。
5. 分散式系統如何進行分佈？
我們來看一下分佈系統進行分佈的常用方式：
1. 雜湊
以雜湊方式把不同的值進行雜湊運算，對映到不同的機器或者節點上。這種方式在擴充套件的時候比較困難，因為資料分散在多個機器上很容易出現分佈不均的情況，常見的雜湊物件有ip，url，id等。
2. 資料範圍
按資料範圍分佈，比如ID在1~100的在機器a上，ID在100~200的在機器b上，諸如此類。這種分佈方法資料比較均勻。如果某個節點處理能力有限，可以直接分裂這個節點。
維護資料分佈的這些原資料，如果量非常大的話，可能會出現單點瓶頸。
因此一定要嚴格控制後設資料量。
3. 資料量
按資料量來分佈資料，是以較為固定的大小將資料劃分為若干的資料塊，再把不同的資料塊分佈到不同的伺服器上。
以資料量來進行分佈的這些資料，也需要被記錄下來作為後設資料來管理。
當叢集規模很大時，後設資料的量也會變大。
4. 副本與資料分佈
這種方式是指把資料給分散到多個伺服器上。如果其中一臺出現問題，請求就會被轉到其他伺服器上。其原理是多個機器互為副本，這是比較理想的實現負載分壓的方式。
5. 一致性雜湊
一致性雜湊。通過雜湊域構造雜湊環，在增加機器時，變動的是其附近的節點，分攤的是附近節點的壓力，其後設資料的維護和按數量分佈的維護方式一致。
我們現在來看一下使用以上方式進行分佈的例子:
GFS, HDFS: 按資料量分佈。
Map reduce: 按GFS資料分佈做本地化。
BigTable, HBase按資料範圍分佈。
Pnuts: 按雜湊方式或者資料範圍分佈。
Dynamo, Cassndra: 按一致性雜湊分佈。
Mola, Armor, BigPipe: 按雜湊方式分佈。
Doris: 按雜湊方式和按資料量分佈進行組合。
6. 分散式應用通常使用的架構型別哪些?
6.1 客戶端伺服器
在這個型別中，分散式系統架構有一個伺服器作為共享資源。比如印表機資料庫或者網路伺服器。它有多個客戶機，這些客戶機決定何時使用共享資源，如何使用和顯示改變資料，並將其送回伺服器，像git這樣的程式碼倉，這是一個很好的例子。
6.2 三層架構
這種架構把系統分為表現層，邏輯層和資料層，這簡化了應用程式的部署，大部分早期的網路應用都是三層的。
6.3 多層架構
上面的三層架構是多層架構的一種特殊形式。
一般會把上面的三層進行更詳細的劃分，比如說以業務的形式進行分層。
6.4 點對點架構
在這種架構中，沒有專門的機器提供服務或管理網路資源。而是將責任統一分配給所有的機器，成為對等機，對等機既可以作為客戶機，也可以作為伺服器。這種架構的例子，包括bittorrent和區塊鏈。
6.5 以資料庫為中心
這種架構是指用一個共享的資料庫，使分散式的各個節點在不需要任何形式直接通訊的情況下，進行協同工作的架構。
7. 分散式系統的優缺點有哪些？
7.1分散式系統的優點
1. 分散式系統中的所有節點都是相互連線的。所以節點可以很容易地與其他節點共享資料。
2. 更多的節點可以很容易地新增到分散式系統中，即可以根據需要進行擴充套件。
3. 一個節點的故障不會導致整個分散式系統的失敗。其他節點仍然可以相互通訊。
4. 硬體資源可以與多個節點共享，而不是隻限於一個節點。
7.2分散式系統的缺點
1. 在分散式系統中很難提供足夠的安全，因為節點以及連線都需要安全。
2. 一些訊息和資料在從一個節點轉移到另一個節點時，可能會在網路中丟失。
3. 與單使用者系統相比，連線到分散式系統的資料庫是相當複雜和難以處理的。
4. 如果分散式系統的所有節點都試圖同時傳送資料，網路中可能會出現過載現象。
小結
最後談一下分散式系統與叢集的關聯。我的觀點是這兩者並不是對立的。
因為分散式系統是通過多個節點的叢集來完成一個任務，讓外界看起來是跟一套系統作為一個整體打交道。
一套分散式系統可以有多個叢集，這些叢集可以業務進行劃分，也可以物理區域進行劃分。每一個叢集可以作為這個分散式系統的一個節點。
這些叢集節點組成的分散式系統，又可以作為單個的節點與其他的節點組成一個叢集。