分散式一致性原理與實踐（一）

一、概述

分散式系統是一個硬體或者軟體元件分佈在不同的網路計算機上，彼此之間僅僅通過訊息傳遞進行通訊和協調的系統。

二、分散式系統的特點

分佈性
分散式系統中的多臺計算機都會在空間上隨意分佈，同時，機器的分佈情況也會隨時變動。
對等性
分散式系統中的計算機沒有主從之分，組成分散式系統的所有計算機節點都是對等的。副本是分散式系統最常見的概念之一，指的是分散式系統對資料和服務提供的一種冗餘方式。
併發性
在一個計算機網路中，程式執行中的併發操作是常見的，可能會併發操作一些共享資源，如資料庫或者分散式儲存等，如何高效的協調分散式併發操作也是分散式系統架構與設計中最大挑戰之一。
缺乏全域性時鐘
因為分散式系統是由一系列在空間上隨意分佈的多個程式組成的，具有明顯的分佈性，這些程式之間通過交換訊息來通訊。因為缺乏全域性時鐘，因此很難界定兩個事件發生的先後順序。所以在設計階段考慮的異常情況，一定會在系統實際執行中發生，並且，在系統執行過程中還會遇到很多在設計時未能考慮到的異常故障，所以在系統設計中不要放過任何異常情況。

三、分散式系統中常見的問題

通訊異常
分散式系統需要在各個節點之間進行通訊，因此每次網路通訊都會伴隨著網路不可用的風險（光纖、路由、DNS等硬體裝置的不可用）。
網路分割槽
由於網路發生異常情況，導致分散式系統中部分節點之間的網路延遲不斷增大，最終導致組成分散式系統中只有部分節點能夠進行正常通訊，這種情況為網路分割槽，俗稱“腦裂”。當出現網路分割槽時，分散式系統就會出現區域性小叢集，在極端情況下，這些小叢集會獨立完成原本需要整個分散式系統才能完成的功能，包括資料的事務處理，這就對分散式一致性提出非常大的挑戰。
三態
因為網路的問題，所以分散式系統每次請求與響應存在特有的“三態”概念，即成功、失敗和超時。由於網路部可靠性，雖然絕大部分情況下，網路通訊能夠接受到成功失敗響應，但網路異常下，就會出現超時現象，通常有以下兩種情況：
1. 由於網路原因，請求並沒有被成功的傳送到接收方，而是在傳送過程就發生了丟失現象。
2. 該請求成功的被接收方處理後，但在響應反饋給傳送方過程中，發生丟失現場。

四、分散式事物

對於分散式事物想必大家都是耳熟能詳的，畢竟所有的分散式系統都會遇到這個問題。一般一個分散式事物可以看作是由多個分散式的操作序列組成的，通常把這一系列分散式的操作成為子事物。因此，分散式事物也可以被定義為一種巢狀型的事物，同時也就具備了ACID的事物特性。但是由於分散式事物中，各個子系統事物的執行是分散式的，因此要實現一種能夠保證ACID特性的分散式事務處理系統就格外的複雜了。所以就出現了諸如CAP和BASE這樣的分散式經典理論。

CAP

CAP理論告訴我們，一個分散式系統不可能同時滿足一致性（c:consistency）、可用性（A:Availability）和分割槽容錯性（P:Partition tolerance）這三個基本需求，最多隻能同時滿足其中的兩項。

一致性
在分散式環境中，一致性是指在多個副本之間是否能夠保持一致的特性。對於資料副本分佈在不同節點的系統來說，如果一個節點資料更新了，卻沒有使第二個節點資料相應的更新，那如果此時讀到第二個節點的時候獲取的就是老資料，這就是典型的資料不一致。如果能做到一個資料更新，所有使用者任何節點讀到的都是新的資料，那麼系統就被認為具有強一致性。
可用性
就是指服務必須一直處於可用狀態，對於使用者每個操作請求總是能夠在有限的時間內返回結果。重點是“有限的時間內” 和“返回結果”。在不同業務場景下下“有限時間”是不同的。而“返回結果”指的是明確的處理結果，即成功或失敗。
分割槽容錯性
在分散式系統遇到任何網路分割槽故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非整個掛掉了。

附贈CAP關係圖：

CAP定理應用

放棄C.A.P	解讀
放棄P	如果放棄P後想避免出現分割槽容錯問題，簡單做法是將所有的資料（或僅僅與事物有關係的資料）都放在一個分散式節點。但需要注意的是放棄P，就代表放棄了系統的擴充套件性。
放棄A	放棄A一旦出現網路分割槽或者其他故障，那麼受影響的服務需要等待恢復，並在此期間不能對外提供服務
放棄C	這裡說的放棄一致性，不是完全放棄，而是放棄資料強一致性，只保留資料最終一致性。具體多久能夠達到資料一致，取決於系統設計，主要包括資料副本在不同節點之間複製時間的長短。

其實從設計角度來看，分散式系統不可能滿足強一致性、可用性、分割槽容錯性這三個需求。對於分散式系統來說，分割槽容錯是基本屬性，因此係統架構師往往把精力放在如何根據業務特點在C （一致性）和 A（可用性）直接尋求平衡。

BASE理論

BASE 是由eBay架構師提出的。BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模網際網路分散式系統實踐的總結，是基於CAP定律逐步演化而來，其核心思想是即使無法做到強一致性，但每個應用都可以根據自身業務特點，才用適當的方式來使系統打到最終一致性。下面看下BASE中的三要素。

基本可用
是指分散式系統出現不可預知的故障時候，允許損失部分可用性，請注意，這絕不是等價於系統不可用。以下兩種典型例子：
1. 響應時間上的損失：正常情況下一個搜尋引擎需要0.5秒返回查詢結果，但由於故障（如系統機房斷網或者失火），查詢結果響應時間增加到2秒。
2. 服務降級：在秒殺搶購等模式中，限制使用者的請求比例，保證系統的穩定性。

弱狀態
也稱為軟狀態，和硬狀態比，是指允許系統中資料存在中間狀態，並認為中間狀態不會影響系統的整體可用性，即允許系統在不同幾點的資料副本之間進行資料同步的過程存在延時。

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

亞馬遜技術長，發表過一篇對最終一致性詳細介紹的文章。他認為最終一致性是一種特殊的弱一致性：系統能夠保證在沒有其他新的更新操作情況下，資料最終一定能夠達到一致的狀態，因此所有客戶端對系統的資料訪問都能夠獲取到最新值。同時，在沒有發生故障的前提下，資料達到一致狀態的時間延遲，取決於網路延遲、系統負載和資料複製方案設計等因素。

在實踐中，最終一致性有五類變種：

因果一致性( causal consistency)
因果一致性指的是，如果程式A在更新完某個資料項後通知了程式B，那麼程式B之後對該資料項的訪問都應該能夠獲取到程式A更新後的最新值，並且如果程式B要對該資料進行更新操作的話，務必基於程式A更新後的最新值，不能發生丟失更新情況。與此同時，與程式A無關係的程式C資料訪問無限制

讀已知所寫（read your write）
指的是，程式A更新資料後，它總是能夠訪問到更新過的最新值。也就是說，我自己讀到的資料一定不會比我上次寫入的資料舊。

會話一致性 （session consistency）
就是系統能夠保證在同一個有效會話中實現“讀已知所寫”的一致性，也就是說，在更新操作後，在同一個會話中始終能獲取到最新值。

單調讀一致性（monotonic read consistency）
指的是如果一個程式從系統中讀取出一個資料項的某個值後，那麼系統對於該程式後續的任何資料訪問都不應該返回更舊的值。

單調寫一致性
一個系統需要能夠保證來自同一個程式的寫操作被順序執行。

以上就是五類系統架構中常用到的一致性變種，可以相互結合設計一個具有最終一致性的分散式系統。總體來說BASE理論面向的是大型高可用可擴充套件的分散式系統，和傳統ACID特性相反，不同於ACID的強一致性模型，提出通過犧牲強一致性來獲得可用性，並允許資料段時間內的不一致，但是最終達到一致狀態。同時，在實際分散式場景中，不同業務對資料的一致性要求不一樣，因此在設計中，ACID和BASE理論往往又會結合使用。

小結

本文圍繞分散式架構發展中碰到的問題，結合CAP、BASE等分散式事物與一致性方面的經典理論，簡單的介紹了下分散式系統。下面會逐步分析分散式系統面臨的問題和解決方案。

---

關注公眾號，將獲得最新文章推送