分佈式理論(二) - BASE理論

時間 2019-11-06

原文原文鏈接

前言

BASE理論是由eBay架構師提出的。BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網分佈式系統實踐的總結，是基於CAP定律逐步演化而來。其核心思想是即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，才用適當的方式來使系統打到最終一致性。算法

正文

1. CAP的3選2僞命題

實際上，不是爲了P（分區容錯性），必須在C（一致性）和A（可用性）之間任選其一。分區的狀況不多出現，CAP在大多時間可以同時知足C和A。數據庫

對於分區存在或者探知其影響的狀況下，須要提供一種預備策略作出處理：編程

探知分區的發生；
進入顯示的分區模式，限制某些操做；
啓動恢復過程，恢復數據一致性，補償分區發生期間的錯誤。

2. BASE理論簡介

BASE理論是Basically Available(基本可用)，Soft State（軟狀態）和Eventually Consistent（最終一致性）三個短語的縮寫。後端

其核心思想是：緩存

既是沒法作到強一致性（Strong consistency），但每一個應用均可以根據自身的業務特色，採用適當的方式來使系統達到最終一致性（Eventual consistency）。網絡

3. BASE理論的內容

基本可用（Basically Available）
軟狀態（Soft State）
最終一致性（Eventually Consistent）

下面展開討論：多線程

3.1. 基本可用

什麼是基本可用呢？假設系統，出現了不可預知的故障，但仍是能用，相比較正常的系統而言：架構

響應時間上的損失：正常狀況下的搜索引擎0.5秒即返回給用戶結果，而基本可用的搜索引擎能夠在2秒做用返回結果。框架
功能上的損失：在一個電商網站上，正常狀況下，用戶能夠順利完成每一筆訂單。可是到了大促期間，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。異步

3.2. 軟狀態

什麼是軟狀態呢？相對於原子性而言，要求多個節點的數據副本都是一致的，這是一種「硬狀態」。

軟狀態指的是：容許系統中的數據存在中間狀態，並認爲該狀態不影響系統的總體可用性，即容許系統在多個不一樣節點的數據副本存在數據延時。

3.3. 最終一致性

上面說軟狀態，而後不可能一直是軟狀態，必須有個時間期限。在期限事後，應當保證全部副本保持數據一致性，從而達到數據的最終一致性。這個時間期限取決於網絡延時、系統負載、數據複製方案設計等等因素。

而在實際工程實踐中，最終一致性分爲5種：

3.3.1. 因果一致性（Causal consistency）

因果一致性指的是：若是節點A在更新完某個數據後通知了節點B，那麼節點B以後對該數據的訪問和修改都是基於A更新後的值。於此同時，和節點A無因果關係的節點C的數據訪問則沒有這樣的限制。

3.3.2. 讀己之所寫（Read your writes）

讀己之所寫指的是：節點A更新一個數據後，它自身老是能訪問到自身更新過的最新值，而不會看到舊值。其實也算一種因果一致性。

3.3.3. 會話一致性（Session consistency）

會話一致性將對系統數據的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現「讀己之所寫」的一致性，也就是說，執行更新操做以後，客戶端可以在同一個會話中始終讀取到該數據項的最新值。

3.3.4. 單調讀一致性（Monotonic read consistency）

單調讀一致性指的是：若是一個節點從系統中讀取出一個數據項的某個值後，那麼系統對於該節點後續的任何數據訪問都不該該返回更舊的值。

3.3.5. 單調寫一致性（Monotonic write consistency）

單調寫一致性指的是：一個系統要可以保證來自同一個節點的寫操做被順序的執行。

在實際的實踐中，這5種系統每每會結合使用，以構建一個具備最終一致性的分佈式系統。

實際上，不僅是分佈式系統使用最終一致性，關係型數據庫在某個功能上，也是使用最終一致性的。好比備份，數據庫的複製過程是須要時間的，這個複製過程當中，業務讀取到的值就是舊的。固然，最終仍是達成了數據一致性。這也算是一個最終一致性的經典案例。

小結

整體來講BASE理論面向的是大型高可用、可擴展的分佈式系統。與傳統ACID特性相反，不一樣於ACID的強一致性模型，BASE提出經過犧牲強一致性來得到可用性，並容許數據段時間內的不一致，可是最終達到一致狀態。同時，在實際分佈式場景中，不一樣業務對數據的一致性要求不同。所以在設計中，ACID和BASE理論每每又會結合使用。