BASE 理論是對 CAP 中一致性和可用性權衡的結果，其來源于對大型互聯網分布式實踐的總結，是基于 CAP 定理逐步演化而來的。
BASE就是為了解決關系數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
可以說基本上都是針對CAP中一些問題的一些容錯或者弱化。

下面就根據個人的理解進行簡單分析解釋。

BASE 不是base這個單詞的含義。

BASE中 ：

• BA 是 Basically Available (基本可用)

  基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性。
  可以理解為在一個平臺中，假設部分出現故障，這個時候系統應該在允許這些故障出現的情況下依舊保持部分功能（應該是核心功能）可以正常使用，另一部分功能出現些許可以允許的問題。
  比如，當出現故障的時候可以允許部分呢功能出現延時，或者跳轉不順暢的情況出現。但不是直接出現錯誤或者異常。
  個人感覺像是再說一種弱可用性，可用，但是不要求必須所有都可用，是一種對可用性要求的妥協。允許一些特殊情況下，系統出現一小部分可容忍的問題。

• S 是Soft state（軟狀態）
  軟狀態，允許部分節點的數據存在一定的延時，這個延時不影響可用性。
  舉個例子，就是一個集群中，需要保持所有節點的數據時時刻刻都一致，這是一種強一致性的要求，這個很有可能會造成可用性的問題。
  軟狀態就是不強制要求在同一個時刻所有節點數據都是一致的，但是也不能說延時延到系統都不能使用了。在保證了可用性的的前提下，允許各個節點在數據的一致性操作的時候有一定的延時。

• E 是Eventually consistent（最終一致性）
  最終一致性很好理解，軟狀態允許有一定延時，所以這個最終一致含義就是在一定的延時過去之后，所有節點的數據必須保持一致。
  相比的假如在更新的同時，所有節點都必須查詢到最新的數據，這樣的話是一種 強一致性 。
  在更新的同時，可以容忍節點查詢到的數據不是最新的那么是一種 弱一致性。

  最終一致性根據更新數據后各進程訪問到數據的時間和方式的不同可以分類為：

  • Causal consistency（因果一致性）
    因果一致性，字面直接理解就是有操作之間有前因后果的要保持一致性。
    假設現在有線程A，線程B，線程C，首先 線程A修改了一條數據，暫且把數據標記為d，在A修改之后并且通知了B線程也就是說這個修改已經可以對B線程可見，那么線程B再在A的基礎上修改的時候必須基于A修改的之后的數據進行操作。這是可以很明顯看到A 和B存在因果關系，A修改的數據可能直接決定了B最后將要修改的數據。這個時候在AB因果之外的C線程看來，就不需要關心AB之間的一致性，所以一致性其實只需要有前因后果的操作之間保持。

  • Read-your-writes consistency （讀己所寫一致性）
    讀己所寫一致性，字面上看，就是讀取數據的時候，假如讀到的是自己修改之后過的數據那么至少應該讀取到自己上一次修改的最新的數據。

  • Session consistency （會話一致性）
    會話一致性將對系統數據的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現“讀己所寫”的一致性，也就是說，執行更新操作之后，客戶端能夠在同一個會話中始終讀取到該數據項的最新值。

  • Monotonic read consistency （單調讀一致性）
    單調讀一致性是指如果一個進程從系統中讀取出一個數據項的某個值后，那么系統對于該進程后續的任何數據訪問都不應該返回更舊的值。

  • Monotonic write consistency （單調寫一致性）
    單調寫一致性是指，一個系統需要能夠保證來自同一個進程的寫操作被順序地執行。

  小結：
  BASE理論首先對于CAP的一種適應妥協和弱化，為了保證可用性，對一致性作出的一些削弱，所以呢可以說BASE是一種反ACID的理論。

參考：
分布式理論(二)——Base 理論
CAP原理與最終一致性
CAP, BASE, 最終一致性和五分鐘原則
CAP原則(CAP定理)、BASE理論

總結

以上是生活随笔為你收集整理的BASE理论的全部內容，希望文章能夠幫你解決所遇到的問題。

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