解決分佈式事務基本思想Base和CPA理論、最終一致性|剛性事務、柔性事務

在學習解決分佈式事務基本思路以前，你們要熟悉一些基本解決分佈式事務概念名詞
好比：CAP與Base理論、柔性事務與剛性事務、理解最終一致性思想，JTA+XA、兩階段與三階段提交等。

 

 如何保證強一致性呢？計算機專業的童鞋在學習關係型數據庫的時候都學習了ACID原理，這裏對ACID作個簡單的介紹。若是想全面的學習ACID原理，請參考ACID

關係型數據庫天生就是解決具備復瑣事務場景的問題，關係型數據庫徹底知足ACID的特性。

數據庫管理系統中事務(transaction)的四個特性（分析時根據首字母縮寫依次解釋）：
原子性（Atomicity） 原子性是指事務是一個不可再分割的工做單元，事務中的操做要麼都發生，要麼都不發生
一致性（Consistency）一致性是指在事務開始以前和事務結束之後，數據庫的完整性約束沒有被破壞。這是說數據庫事務不能破壞關係數據的完整性以及業務邏輯上的一致性
隔離性（Isolation）多個事務併發訪問時，事務之間是隔離的，一個事務不該該影響其它事務運行效果。
持久性（Durability）這是最好理解的一個特性：持久性，意味着在事務完成之後，該事務所對數據庫所做的更改便持久的保存在數據庫之中，並不會被回滾。（完成的事務是系統永久的部分，對系統的影響是永久性的，該修改即便出現致命的系統故障也將一直保持）

 

所謂事務，它是一個操做序列，這些操做要麼都執行，要麼都不執行，它是一個不可分割的工做單位。（執行單個邏輯功能的一組指令或操做稱爲事務）

 

ACID是剛性事務

柔性事務通常遵循BAS和CPA理論，能夠暫時不一致

  

---

 

因爲對系統或者數據進行了拆分，咱們的系統再也不是單機系統，而是分佈式系統，針對分佈式系統的CAP原理包含以下三個元素。
C:Consistency,一致性。在分佈式系統中的全部數據 備份，在同一時刻具備一樣的值，全部節點在同一時刻讀取的數據都是最新的數據副本。

      雙方進行通信的時候 ，或者服務器集羣的時候，必定要保證數據一致性問題，不能發生髒讀等問題。其實通常狀況下能夠作個取捨，能夠暫時不遵循一致性，可是達到最終一致性，只要核心遵循下面的可用性和分區容忍性就能夠。

A:Availability,可用性，好的響應性能。徹底的可用性指的是在任何故障模型下，服務都會在有限的時間內處理完成並進行響應。

 

   好比服務器宕機狀況下 還有備機     
P: Partition tolerance,分區容錯性。儘管網絡上有部分消息丟失，但系統仍然可繼續工做。

   

 

實際開發中大部分只遵循了p和a

CAP原理指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。所以在進行分佈式架構設計時，必須作出取捨。而對於分佈式數據系統，分區容忍性是基本要求，容錯是確定的，不然就失去了價值。所以設計分佈式數據系統，就是在一致性和可用性之間取一個平衡。對於大多數web應用，其實並不須要強一致性，所以犧牲一致性而換取高可用性，是目前多數分佈式數據庫產品的方向。

 補充： 經過軟狀態，能夠暫時不一致，可是最終實現一致。經過補償、重試等。

固然，犧牲一致性，並非徹底無論數據的一致性，不然數據是混亂的，那麼系統可用性再高分佈式再好也沒有了價值。犧牲一致性，只是再也不要求關係型數據庫中的強一致性，而是隻要系統能達到最終一致性便可，考慮到客戶體驗，這個最終一致的時間窗口，要儘量的對用戶透明，也就是須要保障「用戶感知到的一致性」。一般是經過數據的多份異步複製來實現系統的高可用和數據的最終一致性的，「用戶感知到的一致性」的時間窗口則取決於數據複製到一致狀態的時間。

 

CAP原理證實，任何分佈式系統只可同時知足以上兩點，沒法三者兼顧。因爲關係型數據庫是單節點無複製的，所以不具備分區容忍性，可是具備一致性和可用性，而分佈式的服務化系統都須要知足分區容忍性，那麼咱們必須在一致性和可用性之間進行權衡。若是在網絡上有消息丟失，也就是出現了網絡分區，則複製操做可能會被延後，若是這時咱們的使用方等待複製完成再返回，則可能致使在有限時間內沒法返回，就失去了可用性:而若是使用方不等待複製完成，而在主分片寫完後直接返回，則具備了可用性，可是失去了一致性。

 

---

 

Base 理論

BASE 是 Basically Available（基本可用）、Soft state（軟狀態）和 Eventually consistent（最終一致性）三個短語的簡寫，由 eBay 架構師 Dan Pritchett 於 2008 年在《BASE: An Acid Alternative》論文中首次提出。BASE 思想與 ACID 原理大相徑庭，它知足 CAP 原理，經過犧牲強一致性得到可用性， 通常應用於服務化系統的應用層或者大數據處理系統中，經過達到最終一致性來儘可能知足業務的絕大多數需求。
BASE 模型包含以下三個元素：

• BA：（Basically Available ），基本可用。
• S：（ Soft State），軟狀態，狀態能夠在一段時間內不一樣步。
• E：（Eventually Consistent ），最終一致，在必定的時間窗口內， 最終數據達成一致便可。

關於最終一致的幾種變種參見上面，在實際系統實踐中，能夠將若干變種結合起來，來實現各類業務需求。 

BASE理論是基於CAP定理演化而來，是對CAP中一致性和可用性權衡的結果。核心思想：即便沒法作到強一致性，但每一個業務根據自身的特色，採用適當的方式來使系統達到最終一致性。
一、基本可用：指分佈式系統在出現故障的時候，容許損失部分可用性，保證核心可用。但不等價於不可用。好比：搜索引擎0.5秒返回查詢結果，但因爲故障，2秒響應查詢結果；網頁訪問過大時，部分用戶提供降級服務，等。
二、軟狀態：軟狀態是指容許系統存在中間狀態，而且該中間狀態不會影響系統總體可用性。即容許系統在不一樣節點間副本同步的時候存在延時。
三、最終一致性：
系統中的全部數據副本通過必定時間後，最終可以達到一致的狀態，不須要實時保證系統數據的強一致性。最終一致性是弱一致性的一種特殊狀況。BASE理論面向的是大型高可用可擴展的分佈式系統，經過犧牲強一致性來得到可用性。ACID是傳統數據庫經常使用的概念設計，追求強一致性模型。

 案例：支付的過程：

toov5 調用支付寶時候 會傳遞兩個參數 同步回調地址 和 異步回調地址

 同步回調地址：支付完成後，支付寶採用瀏覽器方式重定向回調方

 異步回調地址：支付完成後，採用後臺也就是HttpClient進行調用toov5接口通知支付接口

 

上面場景是兩個事務 （兩個項目） 採用的軟狀態 ，暫時不一致，可是最終一致

當通知接口出現延遲或者異常狀況下，支付寶會發生自動重試。短暫的不一致狀況  

重試過程。toov5注意冪等性

 

這個案例能夠用做 和 外部接口交互的狀況

 

---

柔性事務知足BASE理論（基本可用，最終一致）

剛性事務知足ACID理論

本文主要圍繞分佈式事務當中的柔性事務的處理方式進行討論。

 

柔性事務分爲

1. 兩階段型

2. 補償型             支付寶的案例，有短暫的不一致

3. 異步確保型

4.  最大努力通知型幾種。 因爲支付寶整個架構是SOA架構，所以傳統單機環境下數據庫的ACID事務知足了分佈式環境下的業務須要，以上幾種事務相似就是針對分佈式環境下業務須要設定的

 

 

 具備針對性的總結，小夥伴們能夠繼續往下看：

關係型數據庫嚴格遵循ACID理論。但當數據庫要開始知足橫向擴展、高可用、模式自由等需求時，須要對ACID理論進行取捨，不能嚴格遵循ACID。以CAP理論和BASE理論爲基礎的NoSQL數據庫開始出現。

分佈式存儲的問題 – CAP理論

 

若是咱們期待實現一套嚴格知足ACID的分佈式事務，極可能出現的狀況就是系統的可用性和嚴格一致性發生衝突。在可用性和一致性之間永遠沒法存在一個一箭雙鵰的方案。因爲NoSQL的基本需求就是支持分佈式存儲，嚴格一致性與可用性須要互相取捨，由此延伸出了CAP理論來定義分佈式存儲遇到的問題。

 

CAP理論告訴咱們：一個分佈式系統不可能同時知足一致性(C:Consistency)、可用性(A:Availability)、分區容錯性(P:Partitiontolerance)這三個基本需求，而且最多隻能知足其中的兩項。

 

對於一個分佈式系統來講，分區容錯是基本需求，不然不能稱之爲分佈式系統。所以架構師須要在C和A之間尋求平衡。

 

C – Consistency – 一致性（與ACID的C徹底不一樣）

 

一致性是指「all nodes see the same data at the same time」，即更新操做成功並返回客戶端完成後，全部節點在同一時間的數據徹底一致。

 

對於一致性，能夠分爲從客戶端和服務端兩個不一樣的視角。

 

從客戶端來看，一致性主要指的是多併發訪問時更新過的數據如何獲取的問題。

 

從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。一致性是由於有併發讀寫纔有的問題，所以在理解一致性的問題時，必定要注意結合考慮併發讀寫的場景。

 

從客戶端角度，多進程併發訪問時，更新過的數據在不一樣進程如何獲取的不一樣策略，決定了不一樣的一致性。對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。若是能容忍後續的部分或者所有訪問不到，則是弱一致性。若是通過一段時間後要求能訪問到更新後的數據，則是最終一致性。

 

A – Availability – 可用性

 

可用性是指「Reads and writes always succeed」，即服務一直可用，並且是正常響應時間。

 

對於一個可用性的分佈式系統，每個非故障的節點必須對每個請求做出響應。也就是說，該系統使用的任何算法必須最終終止。當同時要求分區容忍性時，這是一個很強的定義：即便是嚴重的網絡錯誤，每一個請求必須完成。

 

好的可用性主要是指系統可以很好的爲用戶服務，不出現用戶操做失敗或者訪問超時等用戶體驗很差的狀況。在一般狀況下，可用性與分佈式數據冗餘、負載均衡等有着很大的關聯。

 

P – Partition tolerance – 分區容錯性

 

分區容錯性是指「the system continues to operate despite arbitrary message loss or failureof part of the system」，即分佈式系統在遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性和可用性的服務。

 

分區容錯性和擴展性緊密相關。在分佈式應用中，可能由於一些分佈式的緣由致使系統沒法正常運轉。好的分區容錯性要求可以使應用雖然是一個分佈式系統，但看上去卻好像是一個能夠運轉正常的總體。好比如今的分佈式系統中有某一個或者幾個機器宕掉了，其它剩下的機器還可以正常運轉知足系統需求，或者是機器之間有網絡異常，將分佈式系統分隔成未獨立的幾個部分，各個部分還能維持分佈式系統的運做，這樣就具備好的分區容錯性。

 

CA without P

 

若是不要求P（不容許分區），則C（強一致性）和A（可用性）是能夠保證的。但其實分區不是你想不想的問題，而是始終會存在，所以CA的系統更多的是容許分區後各子系統依然保持CA。

 

CP without A

 

若是不要求A（可用），至關於每一個請求都須要在Server之間強一致，而P（分區）會致使同步時間無限延長，如此CP也是能夠保證的。不少傳統的數據庫分佈式事務都屬於這種模式。

 

AP without C

 

要高可用並容許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每一個節點只能用本地數據提供服務，而這樣會致使全局數據的不一致性。如今衆多的NoSQL都屬於此類。

 

CAP理論定義了分佈式存儲的根本問題，但並無指出一致性和可用性之間到底應該如何權衡。因而出現了BASE理論，給出了權衡A與C的一種可行方案。

 

權衡一致性與可用性 - BASE理論

 

Base = Basically Available + Soft state + Eventuallyconsistent 基本可用性+軟狀態+最終一致性，由eBay架構師DanPritchett提出。Base是對CAP中一致性A和可用性C權衡的結果，源於提出者本身在大規模分佈式系統上實踐的總結。核心思想是沒法作到強一致性，但每一個應用均可以根據自身的特色，採用適當方式達到最終一致性。

 

與NoSQL的聯繫：

 NoSQL數據庫種類繁多，可是有一個共同的特色，都是去掉了關係型數據庫的關係型特性。數據之間無關係，這樣就很是容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。