一、分佈式事務解決方案
學習目標 :
- 瞭解本地事務與分佈式事務
- 瞭解CAP理論與BASE理論
- 瞭解常見分佈式事務解決方案
- 能夠通過Seata實現分佈式事務
本地事務
起初，事務僅限於對單一數據庫資源的訪問控制,架構服務化以後，事務的概念延伸到了服務中。倘若將
一個單一的服務操作作爲一個事務，那麼整個服務操作只能涉及一個單一的數據庫資源,這類基於單個服
務單一數據庫資源訪問的事務，被稱爲本地事務(Local Transaction)。
分佈式事務
分佈式事務指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系
統的不同節點之上,且屬於不同的應用，分佈式事務需要保證這些操作要麼全部成功，要麼全部失敗。本
質上來說，分佈式事務就是爲了保證不同數據庫的數據一致性。
最早的分佈式事務應用架構很簡單，不涉及服務間的訪問調用，僅僅是服務內操作涉及到對多個數據庫
資源的訪問
當一個服務操作訪問不同的數據庫資源，又希望對它們的訪問具有事務特性時，就需要採用分佈式事務
來協調所有的事務參與者。
對於上面介紹的分佈式事務應用架構，儘管一個服務操作會訪問多個數據庫資源，但是畢竟整個事務還
是控制在單一服務的內部。如果一個服務操作需要調用另外一個服務，這時的事務就需要跨越多個服務
了。在這種情況下，起始於某個服務的事務在調用另外一個服務的時候，需要以某種機制流轉到另外一
個服務，從而使被調用的服務訪問的資源也自動加入到該事務當中來。下圖反映了這樣一個跨越多個服
務的分佈式事務：
1.2 分佈式事務相關理論
1.2.1 CAP定理
CAP 定理是在 1998年加州大學的計算機科學家 Eric Brewer （埃裏克.布魯爾）提出，分佈式系統有三
個指標
Consistency 一致性
Availability 可用性
Partition tolerance 分區容錯性
它們的第一個字母分別是 C、A、P。Eric Brewer 說，這三個指標不可能同時做到。這個結論就叫做
CAP 定理。
分區容錯 Partition tolerance
大多數分佈式系統都分佈在多個子網絡。每個子網絡就叫做一個區（ partition）。分區容錯的意思是，
區間通信可能失敗。比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可
能無法通信。
上圖中， G1 和 G2 是兩臺跨區的服務器。G1 向 G2 發送一條消息，G2 可能無法收到。系統設計的時
候，必須考慮到這種情況。
一般來說，分區容錯無法避免，因此可以認爲 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A
無法同時做到。
可用性 Availability
Availability 中文叫做"可用性"，意思是隻要收到用戶的請求，服務器就必須給出迴應。
用戶可以選擇向 G1 或 G2 發起讀操作。不管是哪臺服務器，只要收到請求，就必須告訴用戶，到底是
v0 還是 v1，否則就不滿足可用性。
一致性 Consistency
Consistency 中文叫做"一致性"。意思是，寫操作之後的讀操作，必須返回該值。
舉例來說，某條記錄是 v0，用戶向 G1 發起一個寫操作，將其改爲 v1。
問題是，用戶有可能向 G2 發起讀操作，由於 G2 的值沒有發生變化，因此返回的是 v0。G1 和 G2 讀
操作的結果不一致，這就不滿足一致性了。
爲了讓 G2 也能變爲 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 發送一條消息，要求 G2 也改成 v1。
一致性和可用性的矛盾
一致性和可用性，爲什麼不可能同時成立？答案很簡單，因爲可能通信失敗（即出現分區容錯）。
如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有數據同步後，才
能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性。
如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼
無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。
1.2.2 BASE理論
BASE：全稱：Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一
致性）三個短語的縮寫，來自 ebay 的架構師提出。BASE 理論是對 CAP 中一致性和可用性權衡的結
果，其來源於對大型互聯網分佈式實踐的總結，是基於 CAP 定理逐步演化而來的。其核心思想是：
既是無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用
適當的方式來使系統達到最終一致性（Eventual consistency）。
Basically Available(基本可用)
什麼是基本可用呢？假設系統，出現了不可預知的故障，但還是能用，相比較正常的系統而言：
- 響應時間上的損失：正常情況下的搜索引擎 0.5 秒即返回給用戶結果，而基本可用的搜索引擎可以
在 1 秒作用返回結果。 - 功能上的損失：在一個電商網站上，正常情況下，用戶可以順利完成每一筆訂單，但是到了大促期
間，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
Soft state（軟狀態）
什麼是軟狀態呢？相對於原子性而言，要求多個節點的數據副本都是一致的，這是一種 “硬狀態”。
軟狀態指的是：允許系統中的數據存在中間狀態，並認爲該狀態不影響系統的整體可用性，即允許系統
在多個不同節點的數據副本存在數據延時。
Eventually consistent（最終一致性）
系統能夠保證在沒有其他新的更新操作的情況下，數據最終一定能夠達到一致的狀態，因此所有客戶端
對系統的數據訪問最終都能夠獲取到最新的值。
消息最終一致性
消息最終一致性應該是業界使用最多的，其核心思想是將分佈式事務拆分成本地事務進行處理，這種思
路是來源於ebay。我們可以從下面的流程圖中看出其中的一些細節：
基本思路就是：
消息生產方，需要額外建一個消息表，並記錄消息發送狀態。消息表和業務數據要在一個事務裏提交，
也就是說他們要在一個數據庫裏面。然後消息會經過MQ發送到消息的消費方。如果消息發送失敗，會
進行重試發送。
消息消費方，需要處理這個消息，並完成自己的業務邏輯。此時如果本地事務處理成功，表明已經處理
成功了，如果處理失敗，那麼就會重試執行。如果是業務上面的失敗，可以給生產方發送一個業務補償
消息，通知生產方進行回滾等操作。
生產方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送一遍。如果有靠譜
的自動對賬補賬邏輯，這種方案還是非常實用的。
優點： 一種非常經典的實現，避免了分佈式事務，實現了最終一致性。
缺點： 消息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。
基於消息隊列實現分佈式事務
