後端程式設計師必備：分散式事務基礎篇

前言

最近看了幾篇有關於分散式事務的博文，做一下筆記。哈哈~

資料庫事務

資料庫事務（簡稱：事務），是資料庫管理系統執行過程中的一個邏輯單位，由一個有限的資料庫操作序列構成，這些操作要麼全部執行,要麼全部不執行，是一個不可分割的工作單位。

資料庫事務的幾個典型特性：原子性(Atomicity )、一致性( Consistency )、隔離性( Isolation)和永續性(Durabilily)，簡稱就是ACID。

原子性： 事務作為一個整體被執行，包含在其中的對資料庫的操作要麼全部被執行，要麼都不執行。
一致性： 指在事務開始之前和事務結束以後，資料不會被破壞，假如A賬戶給B賬戶轉10塊錢，不管成功與否，A和B的總金額是不變的。
隔離性： 多個事務併發訪問時，事務之間是相互隔離的，即一個事務不影響其它事務執行效果。簡言之，就是事務之間是進水不犯河水的。
永續性： 表示事務完成以後，該事務對資料庫所作的操作更改，將持久地儲存在資料庫之中。

事務的實現原理

本地事務

傳統的單伺服器，單關係型資料庫下的事務，就是本地事務。本地事務由資源管理器管理，JDBC事務就是一個非常典型的本地事務。

事務日誌

innodb事務日誌包括redo log和undo log。

redo log（重做日誌）

redo log通常是物理日誌，記錄的是資料頁的物理修改，而不是某一行或某幾行修改成怎樣，它用來恢復提交後的物理資料頁。

undo log（回滾日誌）

undo log是邏輯日誌，和redo log記錄物理日誌的不一樣。可以這樣認為，當delete一條記錄時，undo log中會記錄一條對應的insert記錄，當update一條記錄時，它記錄一條對應相反的update記錄。

事務ACID特性的實現思想

原子性：是使用 undo log來實現的，如果事務執行過程中出錯或者使用者執行了rollback，系統通過undo log日誌返回事務開始的狀態。
永續性：使用 redo log來實現，只要redo log日誌持久化了，當系統崩潰，即可通過redo log把資料恢復。
隔離性：通過鎖以及MVCC,使事務相互隔離開。
一致性：通過回滾、恢復，以及併發情況下的隔離性，從而實現一致性。

分散式事務

分散式事務： 就是指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上。簡單來說，分散式事務指的就是分散式系統中的事務，它的存在就是為了保證不同資料庫節點的資料一致性。

為什麼需要分散式事務？接下來分兩方面闡述：

微服務架構下的分散式事務

隨著網際網路的快速發展，輕盈且功能劃分明確的微服務，登上了歷史舞臺。比如，一個使用者下訂單，購買直播禮物的服務，被拆分成三個service，分別是金幣服務（coinService），下訂單服務（orderService）、禮物服務（giftService）。這些服務都部署在不同的機器上（節點），對應的資料庫（金幣資料庫、訂單資料庫、禮物資料庫）也在不同節點上。

使用者下單購買禮物，禮物資料庫、金幣資料庫、訂單資料庫在不同節點上，用本地事務是不可以的，那麼如何保證不同資料庫（節點）上的資料一致性呢？這就需要分散式事務啦~

分庫分表下的分散式事務

隨著業務的發展，資料庫的資料日益龐大，超過千萬級別的資料，我們就需要對它分庫分表（以前公司是用mycat分庫分表，後來用sharding-jdbc）。一分庫，資料又分佈在不同節點上啦，比如有的在深圳機房，有的在北京機房~你再想用本地事務去保證，已經無動於衷啦~還是需要分散式事務啦。

比如A轉10塊給B，A的賬戶資料是在北京機房，B的賬戶資料是在深圳機房。流程如下：

CAP 理論&BASE 理論

學習分散式事務，當然需要了解 CAP 理論和BASE 理論。

CAP理論

CAP理論作為分散式系統的基礎理論，指的是在一個分散式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性），這三個要素最多隻能同時實現兩點。

一致性(C：Consistency)：

一致性是指資料在多個副本之間能否保持一致的特性。例如一個資料在某個分割槽節點更新之後，在其他分割槽節點讀出來的資料也是更新之後的資料。

可用性(A：Availability)：

可用性是指系統提供的服務必須一直處於可用的狀態，對於使用者的每一個操作請求總是能夠在有限的時間內返回結果。這裡的重點是"有限時間內"和"返回結果"。

分割槽容錯性（P:Partition tolerance）:

分散式系統在遇到任何網路分割槽故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務。

選擇	說明
CA	放棄分割槽容錯性，加強一致性和可用性，其實就是傳統的單機資料庫的選擇
AP	放棄一致性，分割槽容錯性和可用性，這是很多分散式系統設計時的選擇
CP	放棄可用性，追求一致性和分割槽容錯性，網路問題會直接讓整個系統不可用

BASE 理論

BASE 理論，是對CAP中AP的一個擴充套件，對於我們的業務系統，我們考慮犧牲一致性來換取系統的可用性和分割槽容錯性。BASE是Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個短語的縮寫。

Basically Available

基本可用：通過支援區域性故障而不是系統全域性故障來實現的。如將使用者分割槽在 5 個資料庫伺服器上，一個使用者資料庫的故障隻影響這臺特定主機那 20% 的使用者，其他使用者不受影響。

Soft State

軟狀態，狀態可以有一段時間不同步

Eventually Consistent

最終一致，最終資料是一致的就可以了，而不是時時保持強一致。

分散式事務的幾種解決方案

分散式事務解決方案主要有以下這幾種：

2PC(二階段提交)方案
TCC（Try、Confirm、Cancel）
本地訊息表
最大努力通知
Saga事務

二階段提交方案

二階段提交方案是常用的分散式事務解決方案。事務的提交分為兩個階段：準備階段和提交執行方案。

二階段提交成功的情況

準備階段，事務管理器向每個資源管理器傳送準備訊息，如果資源管理器的本地事務操作執行成功，則返回成功。

提交執行階段，如果事務管理器收到了所有資源管理器回覆的成功訊息，則向每個資源管理器傳送提交訊息，RM 根據 TM 的指令執行提交。如圖：

二階段提交失敗的情況

準備階段，事務管理器向每個資源管理器傳送準備訊息，如果資源管理器的本地事務操作執行成功，則返回成功，如果執行失敗，則返回失敗。

提交執行階段，如果事務管理器收到了任何一個資源管理器失敗的訊息，則向每個資源管理器傳送回滾訊息。資源管理器根據事務管理器的指令回滾本地事務操作，釋放所有事務處理過程中使用的鎖資源。

二階段提交優缺點

2PC方案實現起來簡單，成本較低，但是主要有以下缺點：

單點問題：如果事務管理器出現故障，資源管理器將一直處於鎖定狀態。
效能問題：所有資源管理器在事務提交階段處於同步阻塞狀態，佔用系統資源，一直到提交完成，才釋放資源，容易導致效能瓶頸。
資料一致性問題：如果有的資源管理器收到提交的訊息，有的沒收到，那麼會導致資料不一致問題。

TCC（補償機制）

TCC 採用了補償機制，其核心思想是：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作。

TCC（Try-Confirm-Cancel）模型

TCC（Try-Confirm-Cancel）是通過對業務邏輯的分解來實現分散式事務。針對一個具體的業務服務，TCC 分散式事務模型需要業務系統都實現一下三段邏輯：

try階段：嘗試去執行，完成所有業務的一致性檢查，預留必須的業務資源。

Confirm階段：該階段對業務進行確認提交，不做任何檢查，因為try階段已經檢查過了，預設Confirm階段是不會出錯的。

Cancel 階段：若業務執行失敗，則進入該階段，它會釋放try階段佔用的所有業務資源，並回滾Confirm階段執行的所有操作。

TCC 分散式事務模型包括三部分：主業務服務、從業務服務、業務活動管理器。

主業務服務：主業務服務負責發起並完成整個業務活動。
從業務服務：從業務服務是整個業務活動的參與方，實現Try、Confirm、Cancel操作，供主業務服務呼叫。
業務活動管理器：業務活動管理器管理控制整個業務活動，包括記錄事務狀態，呼叫從業務服務的 Confirm 操作，呼叫從業務服務的 Cancel 操作等。

下面再拿使用者下單購買禮物作為例子來模擬TCC實現分散式事務的過程：

假設使用者A餘額為100金幣，擁有的禮物為5朵。A花了10個金幣，下訂單，購買10朵玫瑰。餘額、訂單、禮物都在不同資料庫。

TCC的Try階段：

生成一條訂單記錄，訂單狀態為待確認。
將使用者A的賬戶金幣中餘額更新為90，凍結金幣為10（預留業務資源）
將使用者的禮物數量為5，預增加數量為10。
Try成功之後，便進入Confirm階段
Try過程發生任何異常，均進入Cancel階段

TCC的Confirm階段：

訂單狀態更新為已支付
更新使用者餘額為90，可凍結為0
使用者禮物數量更新為15，預增加為0
Confirm過程發生任何異常，均進入Cancel階段
Confirm過程執行成功，則該事務結束

TCC的Cancel階段：

修改訂單狀態為已取消
更新使用者餘額回100
更新使用者禮物數量為5

TCC優缺點

TCC方案讓應用可以自定義資料庫操作的粒度，降低了鎖衝突，可以提升效能，但是也有以下缺點：

應用侵入性強，try、confirm、cancel三個階段都需要業務邏輯實現。
需要根據網路、系統故障等不同失敗原因實現不同的回滾策略，實現難度大，一般藉助TCC開源框架，ByteTCC，TCC-transaction，Himly。

本地訊息表

ebay最初提出本地訊息表這個方案，來解決分散式事務問題。業界目前使用這種方案是比較多的，它的核心思想就是將分散式事務拆分成本地事務進行處理。可以看一下基本的實現流程圖：

基本實現思路

傳送訊息方：

需要有一個訊息表，記錄著訊息狀態相關資訊。
業務資料和訊息表在同一個資料庫，即要保證它倆在同一個本地事務。
在本地事務中處理完業務資料和寫訊息表操作後，通過寫訊息到MQ訊息佇列。
訊息會發到訊息消費方，如果傳送失敗，即進行重試。

訊息消費方：

處理訊息佇列中的訊息，完成自己的業務邏輯。
此時如果本地事務處理成功，則表明已經處理成功了。
如果本地事務處理失敗，那麼就會重試執行。
如果是業務上面的失敗，給訊息生產方傳送一個業務補償訊息，通知進行回滾等操作。

生產方和消費方定時掃描本地訊息表，把還沒處理完成的訊息或者失敗的訊息再傳送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。

優點&缺點：

該方案的優點是很好地解決了分散式事務問題，實現了最終一致性。缺點是訊息表會耦合到業務系統中。

最大努力通知

什麼是最大通知

最大努力通知也是一種分散式事務解決方案。下面是企業網銀轉賬一個例子

企業網銀系統呼叫前置介面，跳轉到轉賬頁
企業網銀呼叫轉賬系統介面
轉賬系統完成轉賬處理，向企業網銀系統發起轉賬結果通知，若通知失敗，則轉賬系統按策略進行重複通知。
企業網銀系統未接收到通知，會主動呼叫轉賬系統的介面查詢轉賬結果。
轉賬系統會遇到退匯等情況，會定時回來對賬。

最大努力通知方案的目標，就是發起通知方通過一定的機制，最大努力將業務處理結果通知到接收方。最大努力通知實現機制如下：

最大努力通知解決方案

要實現最大努力通知，可以採用MQ的ack機制。

方案

1.發起方將通知發給MQ。
2.接收通知方監聽MQ訊息。
3.接收通知方收到訊息後，處理完業務，回應ack。
4.接收通知方若沒有回應ack，則MQ會間隔1min、5min、10min等重複通知。
5.接受通知方可用訊息校對介面，保證訊息的一致性。

轉賬業務實現流程圖：

互動流程如下：

1、使用者請求轉賬系統進行轉賬。
2、轉賬系統完成轉賬，將轉賬結果發給MQ。
3、企業網銀系統監聽MQ，接收轉賬結果通知，如果接收不到訊息，MQ會重複傳送通知。接收到轉賬結果，更新轉賬狀態。
4、企業網銀系統也可以主動查詢轉賬系統的轉賬結果查詢介面，更新轉賬狀態。

Saga事務

Saga事務由普林斯頓大學的Hector Garcia-Molina和Kenneth Salem提出，其核心思想是將長事務拆分為多個本地短事務，由Saga事務協調器協調，如果正常結束那就正常完成，如果某個步驟失敗，則根據相反順序一次呼叫補償操作。

saga簡介

Saga = Long Live Transaction (LLT，長活事務)
LLT = T1 + T2 + T3 + ... + Ti（Ti為本地短事務）
每個本地事務Ti 有對應的補償 Ci

Saga的執行順序

正常情況：T1 T2 T3 ... Tn
異常情況：T1 T2 T3 C3 C2 C1

Saga兩種恢復策略

向後恢復，如果任意本地子事務失敗，補償已完成的事務。如異常情況的執行順序T1 T2 Ti Ci C2 C1.
向前恢復，即重試失敗的事務，假設最後每個子事務都會成功。執行順序：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn。

舉個例子，假設使用者下訂單，花10塊錢購買了10多玫瑰，則有

T1=下訂單，T2=扣使用者10塊錢，T3=使用者加10朵玫瑰， T4=庫存減10朵玫瑰

C1=取消訂單，C2= 給使用者加10塊錢，C3 =使用者減10朵玫瑰， C4=庫存加10朵玫瑰

假設事務執行到T4發生異常回滾，在C4的要把玫瑰給庫存加回去的時候，發現使用者的玫瑰都用掉了，這是Saga的一個缺點，由於事務之間沒有隔離性導致的問題。

可以通過以下方案解決這個問題：

在應⽤層⾯加⼊邏輯鎖的邏輯。
Session層⾯隔離來保證串⾏化操作。
業務層⾯採⽤預先凍結資⾦的⽅式隔離此部分資⾦。
業務操作過程中通過及時讀取當前狀態的⽅式獲取更新。

參考與感謝

個人公眾號

覺得寫得好的小夥伴給個點贊+關注啦，謝謝~
同時非常期待小夥伴們能夠關注我公眾號，後面慢慢推出更好的乾貨~嘻嘻