分佈式事務—基礎篇

1.基礎概念

　　1.1.什麼是事務

　　什麼是事務？舉個生活中的例子：你去小賣鋪買東西，「一手交錢，一手交貨」就是一個事務的例子，交錢和交貨必須所有成功，事務纔算成功，任一個活動失敗，事務將撤銷全部已成功的活動。

明白上述例子，再來看事務的定義：

事務能夠看作是一次大的活動，它由不一樣的小活動組成，這些活動要麼所有成功，要麼所有失敗。

　　1.2.本地事務

　　在計算機系統中，更多的是經過關係型數據庫來控制事務，這是利用數據庫自己的事務特性來實現的，所以叫數據庫事務，因爲應用主要靠關係數據庫來控制事務，而數據庫一般和應用在同一個服務器，因此基於關係型數據庫的事務又被稱爲本地事務。

回顧一下數據庫事務的四大特性 ACID：

A（Atomic）：原子性，構成事務的全部操做，要麼都執行完成，要麼所有不執行，不可能出現部分紅功部分失敗的狀況。

C（Consistency）：一致性，在事務執行先後，數據庫的一致性約束沒有被破壞。好比：張三向李四轉100元，轉帳前和轉帳後的數據是正確狀態這叫一致性，若是出現張三轉出100元，李四帳戶沒有增長100元這就出現了數據錯誤，就沒有達到一致性。

I（Isolation）：隔離性，數據庫中的事務通常都是併發的，隔離性是指併發的兩個事務的執行互不干擾，一個事務不能看到其餘事務運行過程的中間狀態。經過配置事務隔離級別能夠避髒讀、重複讀等問題。

D（Durability）：持久性，事務完成以後，該事務對數據的更改會被持久化到數據庫，且不會被回滾。

數據庫事務在實現時會將一次事務涉及的全部操做所有歸入到一個不可分割的執行單元，該執行單元中的全部操做要麼都成功，要麼都失敗，只要其中任一操做執行失敗，都將致使整個事務的回滾

1.3.分佈式事務

隨着互聯網的快速發展，軟件系統由原來的單體應用轉變爲分佈式應用，下圖描述了單體應用向微服務的演變：

　　分佈式系統會把一個應用系統拆分爲可獨立部署的多個服務，所以須要服務與服務之間遠程協做才能完成事務操做，這種分佈式系統環境下由不一樣的服務之間經過網絡遠程協做完成事務稱之爲分佈式事務，例如用戶註冊送積分事務、建立訂單減庫存事務，銀行轉帳事務等都是分佈式事務。

　　咱們知道本地事務依賴數據庫自己提供的事務特性來實現，所以如下邏輯能夠控制本地事務：

　　begin transaction；

　　//1.本地數據庫操做：張三減小金額

　　//2.本地數據庫操做：李四增長金額

　　commit transation;

可是在分佈式環境下，會變成下邊這樣： 

　　begin transaction；

　　//1.本地數據庫操做：張三減小金額

　　//2.遠程調用：讓李四增長金額

　　commit transation;

能夠設想，當遠程調用讓李四增長金額成功了，因爲網絡問題遠程調用並無返回，此時本地事務提交失敗就回滾了張三減小金額的操做，此時張三和李四的數據就不一致了。

　　所以在分佈式架構的基礎上，傳統數據庫事務就沒法使用了，張三和李四的帳戶不在一個數據庫中甚至不在一個應用系統裏，實現轉帳事務須要經過遠程調用，因爲網絡問題就會致使分佈式事務問題。

　　1.4 分佈式事務產生的場景

　　一、典型的場景就是微服務架構 微服務之間經過遠程調用完成事務操做。 好比：訂單微服務和庫存微服務，下單的同時訂單微服務請求庫存微服務減庫存。 簡言之：跨JVM進程產生分佈式事務。

　　二、單體系統訪問多個數據庫實例 當單體系統須要訪問多個數據庫（實例）時就會產生分佈式事務。 好比：用戶信息和訂單信息分別在兩個MySQL實例存儲，用戶管理系統刪除用戶信息，須要分別刪除用戶信息及用戶的訂單信息，因爲數據分佈在不一樣的數據實例，須要經過不一樣的數據庫連接去操做數據，此時產生分佈式事務。 簡言之：跨數據庫實例產生分佈式事務。

 

　　三、多服務訪問同一個數據庫實例 好比：訂單微服務和庫存微服務即便訪問同一個數據庫也會產生分佈式事務，緣由就是跨JVM進程，兩個微服務持有了不一樣的數據庫連接進行數據庫操做，此時產生分佈式事務。

 

 

2.分佈式事務基礎理論

　　經過前面的學習，咱們瞭解到了分佈式事務的基礎概念。與本地事務不一樣的是，分佈式系統之因此叫分佈式，是由於提供服務的各個節點分佈在不一樣機器上，相互之間經過網絡交互。不能由於有一點網絡問題就致使整個系統沒法提供服務，網絡因素成爲了分佈式事務的考量標準之一。所以，分佈式事務須要更進一步的理論支持，接下來，咱們先來學習一下分佈式事務的CAP理論。

　　在講解分佈式事務控制解決方案以前須要先學習一些基礎理論，經過理論知識指導咱們肯定分佈式事務控制的目標，從而幫助咱們理解每一個解決方案。

2.1.CAP理論

2.1.1.理解CAP

　　CAP是 Consistency、Availability、Partition tolerance三個詞語的縮寫，分別表示一致性、可用性、分區容忍性。

下邊咱們分別來解釋：

爲了方便對CAP理論的理解，咱們結合電商系統中的一些業務場景來理解CAP。

以下圖，是商品信息管理的執行流程：

 

總體執行流程以下：

　　一、商品服務請求主數據庫寫入商品信息（添加商品、修改商品、刪除商品）

　　二、主數據庫向商品服務響應寫入成功。

　　三、商品服務請求從數據庫讀取商品信息。

C - Consistency：

　　一致性是指寫操做後的讀操做能夠讀取到最新的數據狀態，當數據分佈在多個節點上，從任意結點讀取到的數據都是最新的狀態。

上圖中，商品信息的讀寫要知足一致性就是要實現以下目標： 

　　一、商品服務寫入主數據庫成功，則向從數據庫查詢新數據也成功。

　　二、商品服務寫入主數據庫失敗，則向從數據庫查詢新數據也失敗。

如何實現一致性？

　　一、寫入主數據庫後要將數據同步到從數據庫。

　　二、寫入主數據庫後，在向從數據庫同步期間要將從數據庫鎖定，待同步完成後再釋放鎖，以避免在新數據寫入成功後，向從數據庫查詢到舊的數據。

分佈式系統一致性的特色：

　　一、因爲存在數據同步的過程，寫操做的響應會有必定的延遲。

　　二、爲了保證數據一致性會對資源暫時鎖定，待數據同步完成釋放鎖定資源。

　　三、若是請求數據同步失敗的結點則會返回錯誤信息，必定不會返回舊數據。

A - Availability ：

　　可用性是指任何事務操做均可以獲得響應結果，且不會出現響應超時或響應錯誤。

上圖中，商品信息讀取知足可用性就是要實現以下目標：

　　一、從數據庫接收到數據查詢的請求則當即可以響應數據查詢結果。

　　二、從數據庫不容許出現響應超時或響應錯誤。

如何實現可用性？

　　一、寫入主數據庫後要將數據同步到從數據庫。

　　二、因爲要保證從數據庫的可用性，不可將從數據庫中的資源進行鎖定。

　　三、即時數據尚未同步過來，從數據庫也要返回要查詢的數據，哪怕是舊數據，若是連舊數據也沒有則能夠按照約定返回一個默認信息，但不能返回錯誤或響應超時。

分佈式系統可用性的特色：

　　一、 全部請求都有響應，且不會出現響應超時或響應錯誤。

P - Partition tolerance ：

　　一般分佈式系統的各各結點部署在不一樣的子網，這就是網絡分區，不可避免的會出現因爲網絡問題而致使結點之間通訊失敗，此時仍可對外提供服務，這叫分區容忍性。

上圖中，商品信息讀寫知足分區容忍性就是要實現以下目標：

　　一、主數據庫向從數據庫同步數據失敗不影響讀寫操做。

　　二、其一個結點掛掉不影響另外一個結點對外提供服務。

如何實現分區容忍性？

　　一、儘可能使用異步取代同步操做，例如使用異步方式將數據從主數據庫同步到從數據，這樣結點之間能有效的實現鬆耦合。

　　二、添加從數據庫結點，其中一個從結點掛掉其它從結點提供服務。

分佈式分區容忍性的特色：

　　一、分區容忍性分是布式系統具有的基本能力。

2.1.2.CAP組合方式

一、上邊商品管理的例子是否同時具有 CAP呢？

在全部分佈式事務場景中不會同時具有CAP三個特性，由於在具有了P的前提下C和A是不能共存的。

好比：

下圖知足了P即表示實現分區容忍：

本圖分區容忍的含義是： 　　　　

　　1）主數據庫經過網絡向從數據同步數據，能夠認爲主從數據庫部署在不一樣的分區，經過網絡進行交互。

　　2）當主數據庫和從數據庫之間的網絡出現問題不影響主數據庫和從數據庫對外提供服務。

　　3）其一個結點掛掉不影響另外一個結點對外提供服務。

若是要實現C則必須保證數據一致性，在數據同步的時候爲防止向從數據庫查詢不一致的數據則須要將從數據庫數據鎖定，待同步完成後解鎖，若是同步失敗從數據庫要返回錯誤信息或超時信息。

　　若是要實現A則必須保證數據可用性，無論任什麼時候候均可以向從數據查詢數據，則不會響應超時或返回錯誤信息。

經過分析發如今知足P的前提下C和A存在矛盾性。 

二、CAP有哪些組合方式呢？

因此在生產中對分佈式事務處理時要根據需求來肯定知足CAP的哪兩個方面。

1）AP：

　　放棄一致性，追求分區容忍性和可用性。這是不少分佈式系統設計時的選擇。

例如：

　　上邊的商品管理，徹底能夠實現AP，前提是隻要用戶能夠接受所查詢的到數據在必定時間內不是最新的便可。

一般實現AP都會保證最終一致性，後面講的BASE理論就是根據AP來擴展的，一些業務場景 好比：訂單退款，今日退款成功，明日帳戶到帳，只要用戶能夠接受在必定時間內到帳便可。

2）CP：

　　放棄可用性，追求一致性和分區容錯性，咱們的zookeeper其實就是追求的強一致，又好比跨行轉帳，一次轉帳請求要等待雙方銀行系統都完成整個事務纔算完成。

3）CA：

　　放棄分區容忍性，即不進行分區，不考慮因爲網絡不通或結點掛掉的問題，則能夠實現一致性和可用性。那麼系統將不是一個標準的分佈式系統，咱們最經常使用的關係型數據就知足了CA。

上邊的商品管理，若是要實現CA則架構以下：

 

主數據庫和從數據庫中間再也不進行數據同步，數據庫能夠響應每次的查詢請求，經過事務隔離級別實現每一個查詢請求均可以返回最新的數據。

2.1.3 總結

　　經過上面咱們已經學習了CAP理論的相關知識，CAP是一個已經被證明的理論：一個分佈式系統最多隻能同時知足一致性（Consistency）、可用性（Availability）和分區容忍性（Partition tolerance）這三項中的兩項。它能夠做爲咱們進行架構設計、技術選型的考量標準。對於多數大型互聯網應用的場景，結點衆多、部署分散，並且如今的集羣規模愈來愈大，因此節點故障、網絡故障是常態，並且要保證服務可用性達到N個9（99.99..%），並要達到良好的響應性能來提升用戶體驗，所以通常都會作出以下選擇：保證P和A，捨棄C強一致，保證最終一致性。

2.2.BASE理論

　　一、理解強一致性和最終一致性

CAP理論告訴咱們一個分佈式系統最多隻能同時知足一致性（Consistency）、可用性（Availability）和分區容忍性（Partition tolerance）這三項中的兩項，其中AP在實際應用中較多，AP即捨棄一致性，保證可用性和分區容忍性，可是在實際生產中不少場景都要實現一致性，好比前邊咱們舉的例子主數據庫向從數據庫同步數據，即便不要一致性，可是最終也要將數據同步成功來保證數據一致，這種一致性和CAP中的一致性不一樣，CAP中的一致性要求在任什麼時候間查詢每一個結點數據都必須一致，它強調的是強一致性，可是最終一致性是容許能夠在一段時間內每一個結點的數據不一致，可是通過一段時間每一個結點的數據必須一致，它強調的是最終數據的一致性。

　　二、Base理論介紹

　　BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫。BASE理論是對CAP中AP的一個擴展，經過犧牲強一致性來得到可用性，當出現故障容許部分不可用但要保證核心功能可用，容許數據在一段時間內是不一致的，但最終達到一致狀態。知足BASE理論的事務，咱們稱之爲「柔性事務」。

　　 基本可用:分佈式系統在出現故障時，容許損失部分可用功能，保證核心功能可用。如，電商網站交易付款出現問題了，商品依然能夠正常瀏覽。

 　　軟狀態:因爲不要求強一致性，因此BASE容許系統中存在中間狀態（也叫軟狀態），這個狀態不影響系統可用性，如訂單的"支付中"、「數據同步中」等狀態，待數據最終一致後狀態改成「成功」狀態。

　　 最終一致:最終一致是指通過一段時間後，全部節點數據都將會達到一致。如訂單的"支付中"狀態，最終會變爲「支付成功」或者"支付失敗"，使訂單狀態與實際交易結果達成一致，但須要必定時間的延遲、等待。