背景

當我們的單個數(shù)據(jù)庫的性能產(chǎn)生瓶頸的時候，我們可能會對數(shù)據(jù)庫進行分區(qū)。這時候事務不能只依靠本地數(shù)據(jù)庫對事務支持來實現(xiàn)了。

集中實現(xiàn)方案

1.兩階段提交(2PC)

假設事務在a，b兩個數(shù)據(jù)庫上。那現(xiàn)在要對這兩個數(shù)據(jù)庫實現(xiàn)事務支持，就是分別操作a，b上的事務，由一個中間件收集a，b操作的結果。若都成功了，就commit， 否則就回滾。

優(yōu)點：強一致性。

缺點：

(1)如commit到數(shù)據(jù)庫過程中出了問題，導致事務可能不會結束。

(2)性能差。涉及多次節(jié)點間的網(wǎng)絡通信，通信時間過長，導致事務時間過長，鎖定的資源也變長了，造成資源等待時間也過長。

2.補償事務(TCC)

TCC 其實就是采用的補償機制，其核心思想是：針對每個操作，都要注冊一個與其對應的確認和補償(撤銷)操作。它分為三個階段：

(1)Try階段主要是對業(yè)務系統(tǒng)做檢測及資源預留

(2)Confirm階段主要是對業(yè)務系統(tǒng)做確認提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。

(3)Cancel階段主要是在業(yè)務執(zhí)行錯誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務取消，預留資源釋放。

優(yōu)點：解決事務過長問題。

缺點：需要編寫額外補償代碼，造成代碼龐大，難以維護。

3.消息隊列

RocketMQ第一階段發(fā)送Prepared消息時，會拿到消息的地址，第二階段執(zhí)行本地事物，第三階段通過第一階段拿到的地址去訪問消息，并修改狀態(tài)。細心的讀者可能又發(fā)現(xiàn)問題了，如果確認消息發(fā)送失敗了怎么辦?RocketMQ會定期掃描消息集群中的事物消息，這時候發(fā)現(xiàn)了Prepared消息，它會向消息發(fā)送者確認，Bob的錢到底是減了還是沒減呢?如果減了是回滾還是繼續(xù)發(fā)送確認消息呢?RocketMQ會根據(jù)發(fā)送端設置的策略來決定是回滾還是繼續(xù)發(fā)送確認消息。這樣就保證了消息發(fā)送與本地事務同時成功或同時失敗。

舉個例子： 去面館吃面。 先去收銀臺付錢， 收銀臺會給你一個小票， 并且通知廚房做面。 廚房做面失敗， 會有大堂經(jīng)理通知你失敗， 并退錢給你。 或者成功了，服務員把你端給你， 然后收回你的小票。消息隊列處理事務大概是這樣的過程。 這里的發(fā)票相當于消息隊列中的消息。 付錢和收到做好的面可以看做1個事務要做的兩件事。 這里還有一些問題， 首先收銀員收了錢卻忘了給你小票呢? 這種情況先開個準備付款小票， 當收到錢后，再確認已經(jīng)付款。 如果忘了給小票肯定還是有個準備付款小票以及查詢付款記錄就知道是不是付款了。消息隊列還會重復消費， 還要注意查重。

4.當做一個任務來處理

一個任務處理過錯可能會有很多步驟， 一般程序做完一步就會寫入日志。 程序處理任務時崩潰時候， 我們可以通過日志判斷任務處理情況， 然后就可以準確修復了。 我們這里可以這樣每處理完事務中一條sql， 就把一個唯一事務id作為記錄插入一個事務登記表中相當于日志。 用一個模塊去掃描這些表就可以找出事務有問題的表然后去修復。這個方案想對實現(xiàn)起來簡單。

優(yōu)點: 由于把事務拆成小的事務， 性能更高。

缺點：補償方案比較麻煩。

以上就是動力節(jié)點小編介紹的"分布式數(shù)據(jù)庫事務詳解"，希望對大家有幫助，想了解更多可查看Java分布式應用教程。動力節(jié)點在線學習教程，針對沒有任何Java基礎的讀者學習,讓你從入門到精通,主要介紹了一些Java基礎的核心知識，讓同學們更好更方便的學習和了解Java編程，感興趣的同學可以關注一下。