終於有人把「分佈式事務」講的這麼簡單明瞭

時間 2019-11-22

標籤終於分佈式事務簡單明瞭欄目系統架構简体版

原文原文鏈接

又或者在網上購物明明已經扣款，可是卻告訴我沒有發生交易。這一系列狀況都是由於沒有事務致使的。這說明了事務在生活中的一些重要性。git

有了事務，你去小賣鋪買東西，那就是一手交錢一手交貨。有了事務，你去網上購物，扣款即產生訂單交易。github

事務的具體定義數據庫

事務提供一種機制將一個活動涉及的全部操做歸入到一個不可分割的執行單元，組成事務的全部操做只有在全部操做均能正常執行的狀況下方能提交，只要其中任一操做執行失敗，都將致使整個事務的回滾。服務器

簡單地說，事務提供一種「要麼什麼都不作，要麼作全套（All or Nothing）」機制。網絡

數據庫本地事務架構

ACID併發

說到數據庫事務就不得不說，數據庫事務中的四大特性 ACID：異步

A：原子性(Atomicity)，一個事務(transaction)中的全部操做，要麼所有完成，要麼所有不完成，不會結束在中間某個環節。分佈式

事務在執行過程當中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務歷來沒有執行過同樣。微服務

就像你買東西要麼交錢收貨一塊兒都執行，要麼發不出貨，就退錢。

C：一致性(Consistency)，事務的一致性指的是在一個事務執行以前和執行以後數據庫都必須處於一致性狀態。

若是事務成功地完成，那麼系統中全部變化將正確地應用，系統處於有效狀態。

若是在事務中出現錯誤，那麼系統中的全部變化將自動地回滾，系統返回到原始狀態。

I：隔離性(Isolation)，指的是在併發環境中，當不一樣的事務同時操縱相同的數據時，每一個事務都有各自的完整數據空間。

由併發事務所作的修改必須與任何其餘併發事務所作的修改隔離。事務查看數據更新時，數據所處的狀態要麼是另外一事務修改它以前的狀態，要麼是另外一事務修改它以後的狀態，事務不會查看到中間狀態的數據。

打個比方，你買東西這個事情，是不影響其餘人的。

D：持久性(Durability)，指的是隻要事務成功結束，它對數據庫所作的更新就必須永久保存下來。

即便發生系統崩潰，從新啓動數據庫系統後，數據庫還能恢復到事務成功結束時的狀態。

打個比方，你買東西的時候須要記錄在帳本上，即便老闆忘記了那也有據可查。

InnoDB 實現原理

InnoDB 是 MySQL 的一個存儲引擎，大部分人對 MySQL 都比較熟悉，這裏簡單介紹一下數據庫事務實現的一些基本原理。

在本地事務中，服務和資源在事務的包裹下能夠看作是一體的，以下圖：

咱們的本地事務由資源管理器進行管理：

而事務的 ACID 是經過 InnoDB 日誌和鎖來保證。事務的隔離性是經過數據庫鎖的機制實現的，持久性經過 Redo Log（重作日誌）來實現，原子性和一致性經過 Undo Log 來實現。

Undo Log 的原理很簡單，爲了知足事務的原子性，在操做任何數據以前，首先將數據備份到一個地方（這個存儲數據備份的地方稱爲 Undo Log）。而後進行數據的修改。

若是出現了錯誤或者用戶執行了 Rollback 語句，系統能夠利用 Undo Log 中的備份將數據恢復到事務開始以前的狀態。

和 Undo Log 相反，Redo Log 記錄的是新數據的備份。在事務提交前，只要將 Redo Log 持久化便可，不須要將數據持久化。

當系統崩潰時，雖然數據沒有持久化，可是 Redo Log 已經持久化。系統能夠根據 Redo Log 的內容，將全部數據恢復到最新的狀態。對具體實現過程有興趣的同窗能夠去自行搜索擴展。

分佈式事務

什麼是分佈式事務

分佈式事務指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不一樣的分佈式系統的不一樣節點之上。

簡單的說，就是一次大的操做由不一樣的小操做組成，這些小的操做分佈在不一樣的服務器上，且屬於不一樣的應用，分佈式事務須要保證這些小操做要麼所有成功，要麼所有失敗。

本質上來講，分佈式事務就是爲了保證不一樣數據庫的數據一致性。

分佈式事務產生的緣由

從上面本地事務來看，咱們能夠分爲兩塊：

Service 產生多個節點
Resource 產生多個節點

Service 多個節點

隨着互聯網快速發展，微服務，SOA 等服務架構模式正在被大規模的使用。

舉個簡單的例子，一個公司以內，用戶的資產可能分爲好多個部分，好比餘額，積分，優惠券等等。

在公司內部有可能積分功能由一個微服務團隊維護，優惠券又是另外的團隊維護。

這樣的話就沒法保證積分扣減了以後，優惠券可否扣減成功。

Resource多個節點

一樣的，互聯網發展得太快了，咱們的 MySQL 通常來講裝千萬級的數據就得進行分庫分表。

對於一個支付寶的轉帳業務來講，你給朋友轉錢，有可能你的數據庫是在北京，而你的朋友的錢是存在上海，因此咱們依然沒法保證他們能同時成功。

分佈式事務的基礎

從上面來看分佈式事務是隨着互聯網高速發展應運而生的，這是一個必然。

咱們以前說過數據庫的 ACID 四大特性，已經沒法知足咱們分佈式事務，這個時候又有一些新的大佬提出一些新的理論。

CAP

CAP 定理，又被叫做布魯爾定理。對於設計分佈式系統(不只僅是分佈式事務)的架構師來講，CAP 就是你的入門理論。

C (一致性)：對某個指定的客戶端來講，讀操做能返回最新的寫操做。

對於數據分佈在不一樣節點上的數據來講，若是在某個節點更新了數據，那麼在其餘節點若是都能讀取到這個最新的數據，那麼就稱爲強一致，若是有某個節點沒有讀取到，那就是分佈式不一致。

A (可用性)：非故障的節點在合理的時間內返回合理的響應(不是錯誤和超時的響應)。可用性的兩個關鍵一個是合理的時間，一個是合理的響應。

合理的時間指的是請求不能無限被阻塞，應該在合理的時間給出返回。合理的響應指的是系統應該明確返回結果而且結果是正確的，這裏的正確指的是好比應該返回 50，而不是返回 40。

P (分區容錯性)：當出現網絡分區後，系統可以繼續工做。打個比方，這裏集羣有多臺機器，有臺機器網絡出現了問題，可是這個集羣仍然能夠正常工做。

熟悉 CAP 的人都知道，三者不能共有，若是感興趣能夠搜索 CAP 的證實，在分佈式系統中，網絡沒法 100% 可靠，分區實際上是一個必然現象。

若是咱們選擇了 CA 而放棄了 P，那麼當發生分區現象時，爲了保證一致性，這個時候必須拒絕請求，可是 A 又不容許，因此分佈式系統理論上不可能選擇 CA 架構，只能選擇 CP 或者 AP 架構。

對於 CP 來講，放棄可用性，追求一致性和分區容錯性，咱們的 ZooKeeper 其實就是追求的強一致。

對於 AP 來講，放棄一致性(這裏說的一致性是強一致性)，追求分區容錯性和可用性，這是不少分佈式系統設計時的選擇，後面的 BASE 也是根據 AP 來擴展。

順便一提，CAP 理論中是忽略網絡延遲，也就是當事務提交時，從節點 A 複製到節點 B 沒有延遲，可是在現實中這個是明顯不可能的，因此總會有必定的時間是不一致。

同時 CAP 中選擇兩個，好比你選擇了 CP，並非叫你放棄 A。由於 P 出現的機率實在是過小了，大部分的時間你仍然須要保證 CA。

就算分區出現了你也要爲後來的 A 作準備，好比經過一些日誌的手段，是其餘機器回覆至可用。

BASE

BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫，是對 CAP 中 AP 的一個擴展。

基本可用：分佈式系統在出現故障時，容許損失部分可用功能，保證核心功能可用。

軟狀態：容許系統中存在中間狀態，這個狀態不影響系統可用性，這裏指的是 CAP 中的不一致。

最終一致：最終一致是指通過一段時間後，全部節點數據都將會達到一致。

BASE 解決了 CAP 中理論沒有網絡延遲，在 BASE 中用軟狀態和最終一致，保證了延遲後的一致性。

BASE 和 ACID 是相反的，它徹底不一樣於 ACID 的強一致性模型，而是經過犧牲強一致性來得到可用性，並容許數據在一段時間內是不一致的，但最終達到一致狀態。

分佈式事務解決方案

有了上面的理論基礎後，這裏開始介紹幾種常見的分佈式事務的解決方案。

是否真的要分佈式事務

在說方案以前，首先你必定要明確你是否真的須要分佈式事務？

上面說過出現分佈式事務的兩個緣由，其中有個緣由是由於微服務過多。我見過太多團隊一我的維護幾個微服務，太多團隊過分設計，搞得全部人疲勞不堪。

而微服務過多就會引出分佈式事務，這個時候我不會建議你去採用下面任何一種方案，而是請把須要事務的微服務聚合成一個單機服務，使用數據庫的本地事務。

由於不論任何一種方案都會增長你係統的複雜度，這樣的成本實在是過高了，千萬不要由於追求某些設計，而引入沒必要要的成本和複雜度。

若是你肯定須要引入分佈式事務能夠看看下面幾種常見的方案。

2PC

說到 2PC 就不得不聊數據庫分佈式事務中的 XA Transactions。

在 XA 協議中分爲兩階段：

事務管理器要求每一個涉及到事務的數據庫預提交(precommit)此操做，並反映是否能夠提交。
事務協調器要求每一個數據庫提交數據，或者回滾數據。

優勢：

儘可能保證了數據的強一致，實現成本較低，在各大主流數據庫都有本身實現，對於 MySQL 是從 5.5 開始支持。

缺點：

單點問題：事務管理器在整個流程中扮演的角色很關鍵，若是其宕機，好比在第一階段已經完成，在第二階段正準備提交的時候事務管理器宕機，資源管理器就會一直阻塞，致使數據庫沒法使用。
同步阻塞：在準備就緒以後，資源管理器中的資源一直處於阻塞，直到提交完成，釋放資源。
數據不一致：兩階段提交協議雖然爲分佈式數據強一致性所設計，但仍然存在數據不一致性的可能。

好比在第二階段中，假設協調者發出了事務 Commit 的通知，可是由於網絡問題該通知僅被一部分參與者所收到並執行了 Commit 操做，其他的參與者則由於沒有收到通知一直處於阻塞狀態，這時候就產生了數據的不一致性。

總的來講，XA 協議比較簡單，成本較低，可是其單點問題，以及不能支持高併發(因爲同步阻塞)依然是其最大的弱點。

TCC

關於 TCC（Try-Confirm-Cancel）的概念，最先是由 Pat Helland 於 2007 年發表的一篇名爲《Life beyond Distributed Transactions：an Apostate’s Opinion》的論文提出。

TCC 事務機制相比於上面介紹的 XA，解決了以下幾個缺點：

解決了協調者單點，由主業務方發起並完成這個業務活動。業務活動管理器也變成多點，引入集羣。
同步阻塞：引入超時，超時後進行補償，而且不會鎖定整個資源，將資源轉換爲業務邏輯形式，粒度變小。
數據一致性，有了補償機制以後，由業務活動管理器控制一致性。

對於 TCC 的解釋：

Try 階段：嘗試執行，完成全部業務檢查（一致性），預留必需業務資源（準隔離性）。
Confirm 階段：確認真正執行業務，不做任何業務檢查，只使用 Try 階段預留的業務資源，Confirm 操做知足冪等性。要求具有冪等設計，Confirm 失敗後須要進行重試。
Cancel 階段：取消執行，釋放 Try 階段預留的業務資源，Cancel 操做知足冪等性。Cancel 階段的異常和 Confirm 階段異常處理方案基本上一致。

舉個簡單的例子：若是你用 100 元買了一瓶水， Try 階段：你須要向你的錢包檢查是否夠 100 元並鎖住這 100 元，水也是同樣的。

若是有一個失敗，則進行 Cancel(釋放這 100 元和這一瓶水)，若是 Cancel 失敗不論什麼失敗都進行重試 Cancel，因此須要保持冪等。

若是都成功，則進行 Confirm，確認這 100 元被扣，和這一瓶水被賣，若是 Confirm 失敗不管什麼失敗則重試(會依靠活動日誌進行重試)。

對於 TCC 來講適合一些：

強隔離性，嚴格一致性要求的活動業務。
執行時間較短的業務。

實現參考：https://github.com/liuyangming/ByteTCC/。

本地消息表

本地消息表這個方案最初是 eBay 提出的，eBay 的完整方案 https://queue.acm.org/detail.cfm?id=1394128。

此方案的核心是將須要分佈式處理的任務經過消息日誌的方式來異步執行。消息日誌能夠存儲到本地文本、數據庫或消息隊列，再經過業務規則自動或人工發起重試。

人工重試更多的是應用於支付場景，經過對帳系統對過後問題的處理。

對於本地消息隊列來講核心是把大事務轉變爲小事務。仍是舉上面用 100 元去買一瓶水的例子。

1. 當你扣錢的時候，你須要在你扣錢的服務器上新增長一個本地消息表，你須要把你扣錢和減去水的庫存寫入到本地消息表，放入同一個事務(依靠數據庫本地事務保證一致性）。

2. 這個時候有個定時任務去輪詢這個本地事務表，把沒有發送的消息，扔給商品庫存服務器，叫它減去水的庫存，到達商品服務器以後，這時得先寫入這個服務器的事務表，而後進行扣減，扣減成功後，更新事務表中的狀態。

3. 商品服務器經過定時任務掃描消息表或者直接通知扣錢服務器，扣錢服務器在本地消息表進行狀態更新。

4. 針對一些異常狀況，定時掃描未成功處理的消息，進行從新發送，在商品服務器接到消息以後，首先判斷是不是重複的。

若是已經接收，再判斷是否執行，若是執行在立刻又進行通知事務；若是未執行，須要從新執行由業務保證冪等，也就是不會多扣一瓶水。

本地消息隊列是 BASE 理論，是最終一致模型，適用於對一致性要求不高的狀況。實現這個模型時須要注意重試的冪等。

MQ 事務

在 RocketMQ 中實現了分佈式事務，其實是對本地消息表的一個封裝，將本地消息表移動到了 MQ 內部。

下面簡單介紹一下MQ事務，若是想對其詳細瞭解能夠參考：https://www.jianshu.com/p/453c6e7ff81c。

基本流程以下：

第一階段 Prepared 消息，會拿到消息的地址。
第二階段執行本地事務。
第三階段經過第一階段拿到的地址去訪問消息，並修改狀態。消息接受者就能使用這個消息。

若是確認消息失敗，在 RocketMQ Broker 中提供了定時掃描沒有更新狀態的消息。

若是有消息沒有獲得確認，會向消息發送者發送消息，來判斷是否提交，在 RocketMQ 中是以 Listener 的形式給發送者，用來處理。

若是消費超時，則須要一直重試，消息接收端須要保證冪等。若是消息消費失敗，這時就須要人工進行處理，由於這個機率較低，若是爲了這種小几率時間而設計這個複雜的流程反而得不償失。

Saga 事務

Saga 是 30 年前一篇數據庫倫理提到的一個概念。其核心思想是將長事務拆分爲多個本地短事務，由 Saga 事務協調器協調，若是正常結束那就正常完成，若是某個步驟失敗，則根據相反順序一次調用補償操做。

Saga 的組成：每一個 Saga 由一系列 sub-transaction Ti 組成，每一個 Ti 都有對應的補償動做 Ci，補償動做用於撤銷 Ti 形成的結果。這裏的每一個 T，都是一個本地事務。

能夠看到，和 TCC 相比，Saga 沒有「預留 try」動做，它的 Ti 就是直接提交到庫。

Saga 的執行順序有兩種：

T1，T2，T3，...，Tn。
T1，T2，...，Tj，Cj，...，C2，C1，其中 0 < j < n 。

Saga 定義了兩種恢復策略：

向後恢復，即上面提到的第二種執行順序，其中 j 是發生錯誤的 sub-transaction，這種作法的效果是撤銷掉以前全部成功的 sub-transation，使得整個 Saga 的執行結果撤銷。
向前恢復，適用於必需要成功的場景，執行順序是相似於這樣的：T1，T2，...，Tj(失敗)，Tj(重試)，...，Tn，其中 j 是發生錯誤的 sub-transaction。該狀況下不須要 Ci。

這裏要注意的是，在 Saga 模式中不能保證隔離性，由於沒有鎖住資源，其餘事務依然能夠覆蓋或者影響當前事務。

仍是拿 100 元買一瓶水的例子來講，這裏定義：