分散式系統

為什麼會出現分散式系統呢？

我們發現使用網際網路的使用者越來越多，我們需要為越來越多的使用者提供服務。那麼我們的伺服器就要求效能越來越高，但是總是會出現瓶頸。並且我們要為使用者提供長效穩定的服務，不能因為網路服務商的原因或者自然災害導致整個服務不可用。

因此有了分散式系統。

分散式系統是由一組通過網路進行通訊、為了完成共同的任務而協調工作的計算機節點組成的系統。分散式系統的出現是為了用廉價的、普通的機器完成單個計算機無法完成的計算、儲存任務。其目的是利用更多的機器，處理更多的資料。

首先需要明確的是，只有當單個節點的處理能力無法滿足日益增長的計算、儲存任務的時候，且硬體的提升（加記憶體、加磁碟、使用更好的CPU）高昂到得不償失的時候，應用程式也不能進一步優化的時候，我們才需要考慮分散式系統。因為，分散式系統要解決的問題本身就是和單機系統一樣的，而由於分散式系統多節點、通過網路通訊的拓撲結構，會引入很多單機系統沒有的問題，為了解決這些問題又會引入更多的機制、協議，帶來更多的問題。。。

在很多文章中，主要講分散式系統分為分散式計算（computation）與分散式儲存（storage）。計算與儲存是相輔相成的，計算需要資料，要麼來自實時資料（流資料），要麼來自儲存的資料；而計算的結果也是需要儲存的。在作業系統中，對計算與儲存有非常詳盡的討論，分散式系統只不過將這些理論推廣到多個節點罷了。

那麼分散式系統怎麼將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對於計算，那麼就是對計算任務進行切換，每個節點算一些，最終彙總就行了，這就是MapReduce的思想；對於儲存，更好理解一下，每個節點存一部分資料就行了。當資料規模變大的時候，Partition是唯一的選擇，同時也會帶來一些好處：

　　（1）提升效能和併發，操作被分發到不同的分片，相互獨立

　　（2）提升系統的可用性，即使部分分片不能用，其他分片不會受到影響

　　理想的情況下，有分片就行了，但事實的情況卻不大理想。原因在於，分散式系統中有大量的節點，且通過網路通訊。單個節點的故障（程式crash、斷電、磁碟損壞）是個小概率事件，但整個系統的故障率會隨節點的增加而指數級增加，網路通訊也可能出現斷網、高延遲的情況。在這種一定會出現的“異常”情況下，分散式系統還是需要繼續穩定的對外提供服務，即需要較強的容錯性。最簡單的辦法，就是冗餘或者複製集（Replication），即多個節點負責同一個任務，最為常見的就是分散式儲存中，多個節點複雜儲存同一份資料，以此增強可用性與可靠性。同時，Replication也會帶來效能的提升，比如資料的locality可以減少使用者的等待時間。

　　下面這種來自Distributed systems for fun and profit  的圖形象生動說明了Partition與Replication是如何協作的。 

分散式系統存在的問題？

第一，異構的機器與網路：

　　　　分散式系統中的機器，配置不一樣，其上執行的服務也可能由不同的語言、架構實現，因此處理能力也不一樣；節點間通過網路連線，而不同網路運營商提供的網路的頻寬、延時、丟包率又不一樣。怎麼保證大家齊頭並進，共同完成目標，這四個不小的挑戰。

第二，普遍的節點故障：

　　　　雖然單個節點的故障概率較低，但節點數目達到一定規模，出故障的概率就變高了。分散式系統需要保證故障發生的時候，系統仍然是可用的，這就需要監控節點的狀態，在節點故障的情況下將該節點負責的計算、儲存任務轉移到其他節點

第三，不可靠的網路：

　　節點間通過網路通訊，而網路是不可靠的。可能的網路問題包括：網路分割、延時、丟包、亂序。

　　相比單機過程呼叫，網路通訊最讓人頭疼的是超時：節點A向節點B發出請求，在約定的時間內沒有收到節點B的響應，那麼B是否處理了請求，這個是不確定的，這個不確定會帶來諸多問題，最簡單的，是否要重試請求，節點B會不會多次處理同一個請求。

總而言之，分散式的挑戰來自不確定性，不確定計算機什麼時候crash、斷電，不確定磁碟什麼時候損壞，不確定每次網路通訊要延遲多久，也不確定通訊對端是否處理了傳送的訊息。而分散式的規模放大了這個不確定性，不確定性是令人討厭的，所以有諸多的分散式理論、協議來保證在這種不確定性的情況下，系統還能繼續正常工作。

分散式提出的兩種理論！

CAP理論

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

• 一致性（Consistence） :所有節點訪問同一份最新的資料副本
• 可用性（Availability）:每次請求都能獲取到非錯的響應——但是不保證獲取的資料為最新資料
• 分割槽容錯性（Partition tolerance） : 分散式系統在遇到某節點或網路分割槽故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

CAP僅適用於原子讀寫的NOSQL場景中，並不適合資料庫系統。現在的分散式系統具有更多特性比如擴充套件性、可用性等等，在進行系統設計和開發時，我們不應該僅僅侷限在CAP問題上。

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

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

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

我在網上找了很多文章想看一下有沒有文章提到這個不是所謂的3選2，用百度半天沒找到了一篇，用谷歌搜尋找到一篇比較不錯的，如果想深入學習一下CAP就看這篇文章把，我這裡就不多BB了：《分散式系統之CAP理論》 ： http://www.cnblogs.com/hxsyl/p/4381980.html

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. 最終一致性

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