分布式事務

本質上來說，分布式事務就是為了保證不同數據庫的數據一致性。

1. 分布式理論
   1.1. CAP定律
   CAP指的是：一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。
   CAP定律說的是，在一個分布式系統中，最多只能滿足C、A、P中的兩個，不可能三個同時滿足。
   在分布式系統中，網絡無法 100% 可靠，分區其實是一個必然現象。如果我們選擇了 CA 而放棄了 P，那么當發生分區現象時，為了保證一致性，這個時候必須拒絕請求，但是 A 又不允許，所以分布式系統理論上不可能選擇 CA 架構，只能選擇 CP 或者 AP 架構。
   而且，顯然，任何橫向擴展策略都要依賴于數據分區。因此，設計人員必須在一致性與可用性之間做出選擇。
   1.2. BASE理論
   往往在分布式系統中無法實現完全一致性，于是有了BASE理論，它是對CAP定律的進一步擴充
   BASE指的是：
   BASE理論是對CAP中的一致性和可用性進行一個權衡的結果
   BASE理論核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性
   BASE理論是通過犧牲強一致性來獲得可用性，并允許數據在一段時間內是不一致的，但最終達到一致狀態
2. 分布式事務解決方案
   2.1. 基于XA協議的兩階段提交
   XA協議包含兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，目前主流的關系型數據庫都實現了XA接口，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。
   
   優點：盡量保證了數據的強一致，適合對數據強一致要求很高的關鍵領域。（其實也不能100%保證強一致）
   缺點：XA協議遵循強一致性。在事務執行過程中，各個節點占用著數據庫資源，只有當所有節點準備完畢，事務協調者才會通知提交，參與者提交后釋放資源。這樣的過程有著非常明顯的性能問題。
   （PS：XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，并且引入了超時機制。這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。）
   兩階段提交方案鎖定資源時間長，對性能影響很大，基本不適合解決微服務事務問題。
   2.2. TCC方案
   TCC 其實就是采用的補償機制，其核心思想是：針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作。
   其將整個業務邏輯的每個分支顯式的分成了Try、Confirm、Cancel三個操作。Try部分完成業務的準備工作，confirm部分完成業務的提交，cancel部分完成事務的回滾。
   
   拿前面的下單的例子來說，服務A的try相當于查詢是否有可用的積分，Confirm相當于扣減積分，Cancel相當于增加積分。
   優點：跟2PC比起來，實現以及流程相對簡單了一些，但數據的一致性比2PC也要差一些
   缺點：TCC屬于應用層的一種補償方式，所以需要程序員在實現的時候多寫很多補償的代碼，而且補償的時候也有可能失敗，在一些場景中，一些業務流程可能用TCC不太好定義及處理。
   2.3. 本地消息表
   其基本的設計思想是將遠程分布式事務拆分成一系列的本地事務。
   消息生產方，需要額外建一個消息表，并記錄消息發送狀態。消息表和業務數據要在一個事務里提交，也就是說他們要在一個數據庫里面。然后消息會經過MQ發送到消息的消費方。如果消息發送失敗，會進行重試發送。
   消息消費方，需要處理這個消息，并完成自己的業務邏輯。此時如果本地事務處理成功，表明已經處理成功了，如果處理失敗，那么就會重試執行。如果是業務上面的失敗，可以給生產方發送一個業務補償消息，通知生產方進行回滾等操作。
   生產方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。
   本地消息表是一個比較好的做法，這樣可以有效防止重復消息處理
   以轉賬為例，這種方式的過程是這樣的：
   有了消息表以后，可以防止重復、可以重試、保證消息不丟失、做冪等性校驗
   優點：一種非常經典的實現，避免了分布式事務，實現了最終一致性。
   缺點：消息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。
   2.4. MQ（非事務消息）
   如果不把本地數據庫操作和消息投遞放在同一個事務中，那么很難保證本地事務成功后消息一定發送成功
   如果把它們放在同一個事務中，那么考慮下面幾種情況：
   以上三種情況都是正常的，不會有什么問題
   然而，考慮下面這種情況：
   本地數據庫操作成功，消息投遞成功，應用服務器掛了，事務回滾，于是不一致出現了，即本地數據庫操作沒成功，而消息卻發成功了
   如果這是轉賬的話，對方會無緣無故多出一筆錢
   究其原因，是因為發消息不是數據庫操作，它不受ACID的限制，也就是說數據庫事務管不了發消息，因為他們不是同一個數據庫的同一個事務，當然還有一個原因是發出去的消息是無法撤銷的。（PS：在后面將要介紹的RocketMQ的事務消息可以撤銷）
   而上面消息表的話，是同一個數據庫的同一個事務，因此不會出現這種問題
   綜上，這種方式有一定的風險，它無法保證本地數據庫操作 與 消息投遞的一致性，不建議使用
   2.5. MQ（事務消息）
   目前，僅阿里云的RocketMQ支持事務消息。幫助用戶實現類似 X/Open XA 的分布事務功能，通過 MQ 事務消息能達到分布式事務的最終一致。
   
   說明：
   其中，事務消息發送對應步驟1、2、3、4，事務消息回查對應步驟5、6、7
   2.6. GTS
   全局事務服務（Global Transaction Service，簡稱 GTS）是一款高性能、高可靠、接入簡單的分布式事務中間件，用于解決分布式環境下的數據一致性問題。GTS 可以保證分布式系統中的分布式事務的 ACID 特性。它是阿里云的一款產品。