分佈式事務
分佈式事務就是一個大的操作由不同的小操作組成，這些小的操作分佈在不同的服務器上，且屬於不同的應用，分佈式事務需要保證這些小操作要麼全部成功，要麼全部失敗。本質上來說，分佈式事務就是爲了保證不同數據庫的數據一致性。
CAP定理
分佈式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分區容忍性（P：Partition Tolerance），最多隻能同時滿足其中兩項。
- C（一致性）：一致性指的是多個數據副本能否保持一致性的狀態。對系統的一個數據更新之後，如果所有用戶都能夠讀取到最新的值，該系統就被認爲具有強一致性。
- A（可用性）：可用性指分佈式系統在面對各種異常時可以提供正常服務的能力。
- P（分區容忍性）：當出現網絡分區後，系統能夠繼續工作。打個比方，集羣有多臺機器，有臺機器網絡出現了問題，但是這個集羣仍然可以正常工作。
在分佈式系統中，分區容忍性必不可少，因爲需要總是假設網絡是不可靠的。因此只能是保證CP或者AP。
- 爲了保證一致性（CP），不能訪問未同步完成的節點，失去了部分可用性。
- 爲了保證可用性（AP），允許讀取所有節點的數據，但是數據可能不一致。
2PC
兩階段提交（Two-phase Commit，2PC），通過引入事務協調者來協調參與者的行爲，並最終決定這些參與者是否要真正執行事務。
- 準備階段（第一階段）：事務協調者詢問參與者事務是否執行預提交（將Undo信息和Redo信息寫入日誌，但不commit事務）成功，參與者返回事務預提交執行結果。
- 提交階段（第二階段）：如果事務在每個參與者上都預提交成功，事務協調者發送通知讓參與者提交事務（執行commit操作），參與者執行事務提交成功，會釋放在整個事務期間內佔用的資源，然後向事務協調者發送“完成”消息。事務協調者收到所有參與者節點反饋的“完成”消息後，完成事務。回滾操作類似（參與者利用之前寫入的Undo信息執行回滾）。
2PC存在的問題
- 同步阻塞：所有事務參與者在等待其他事務參與者響應的時候都處於同步阻塞狀態，無法進行其他操作
- 單點問題：事務協調者在2PC中扮演着重要的角色，發生單點故障將會造成很大影響。
- 數據不一致問題：如果在提交階段，事務協調者只發送了部分的commit消息或者因爲網絡原因只有部分參與者接收到了commit消息，會導致只有部分事務參與者沒有提交事務，造成數據不一致。
本地消息表
本地消息表的核心就是將分佈式處理的任務通過消息日誌（如本地消息表）的方式來異步執行。本地消息表和業務數據表處於同一個數據庫，這樣就可以利用本地事務保證對這兩個表的操作滿足事務特性，並且利用消息隊列來保證最終一致性。
例如A轉賬給B一百元，業務數據表中執行A-100和將B+100寫入本地消息表這兩個操作處於同一個本地事務中。
- 在分佈式事務操作中的一方完成寫業務數據的操作之後向本地消息表發送一個消息，本地事務能保證這個消息一定會被寫入本地消息表中。
- 之後將本地消息表中的消息轉發到消息隊列中，如果轉發成功則將消息從本地消息表中刪除，否則繼續重新轉發。
- 在分佈式事務操作的另一方從消息隊列中讀取一個消息，並執行消息中的操作。
本地消息表是BASE理論，只能保證最終一致性，適用於對一致性要求不高的場景。
RocketMQ分佈式事務
RocketMQ 事務消息的設計流程同樣借鑑了兩階段提交理論，通過在執行本地事務前後發送兩條消息來保證本地事務與發送消息的原子性，過程如下圖：
事務消息詳細過程說明
- 事務發起方首先發送 prepare 消息到 MQ。
- 在發送 prepare 消息成功後執行本地事務。
- 根據本地事務執行結果返回 commit 或者是 rollback。
- Producer發送確認消息到broker（也就是將步驟3執行的結果發送給broker），這裏可能broker未收到確認消息，下面分兩種情況分析：
- 如果broker收到了確認消息：如果收到的結果是commit，則broker視爲整個事務過程執行成功，將消息下發給Conusmer端消費；如果收到的結果是rollback，則broker視爲本地事務執行失敗，broker刪除Half消息，不下發給consumer。
- 如果broker未收到了確認消息：broker定時回查本地事務的執行結果；（由用戶實現）如果本地事務已經執行則返回commit；如果未執行，則返回rollback；
- Consumer 端的消費成功機制有 MQ 保證，如果消費超時，則需要重試，Consumer端需要保證冪等。如果消息仍然消費失敗（小概率事件），則需要人工來進行處理。