1 數(shù)據(jù)庫單機(jī)事務(wù)的實(shí)現(xiàn)原理
- 數(shù)據(jù)庫事務(wù)的ACID特性；
- MySQL的undo和redo日志的例子；
2 經(jīng)典的X/OpenDTP事務(wù)模型
如果一個(gè)事務(wù)內(nèi)的SQL，要分別操作幾個(gè)獨(dú)立的數(shù)據(jù)庫服務(wù)器上的數(shù)據(jù)，那這種事務(wù)就變成了分布式事務(wù)。于是就有技術(shù)達(dá)人制定了首個(gè)分布式事務(wù)表中規(guī)范-X/OpenDTP，此規(guī)范提出的二階段提交模型(2PC)和“TCP三次握手”一樣成為經(jīng)典。
AP：應(yīng)用程序。AP負(fù)責(zé)發(fā)送XA指令，觸發(fā)分布式事務(wù)，由TM接收，并發(fā)送給相關(guān)的RM。
RM：數(shù)據(jù)庫或者很少被使用的消息中間件。負(fù)責(zé)執(zhí)行XA指令，每個(gè)RM只負(fù)責(zé)執(zhí)行自己的指令。
TM：事務(wù)管理器、事務(wù)協(xié)調(diào)者，負(fù)責(zé)接收來自AP發(fā)送的XA事務(wù)指令，并且調(diào)度和協(xié)調(diào)參與事務(wù)的所有RM，確保事務(wù)正確完成或者回滾。
X/OpenDTP模型中最為知名的就是兩階段提交協(xié)議。在X/OpenDTP模型中，當(dāng)一個(gè)分布式事務(wù)所涉及的SQL邏輯都執(zhí)行完成，并到了RMs最后提交事務(wù)的關(guān)鍵時(shí)刻，為了避免分布式系統(tǒng)所固有的不可靠性導(dǎo)致事務(wù)提交失敗，TM決定，實(shí)施兩步走的方案：
① 先發(fā)起投票表決，通知所有RM先完成事務(wù)提交過程所涉及的各種復(fù)雜的準(zhǔn)備工作，比如寫redo、undo日志，盡量把提交過程中所有消耗時(shí)間的操作和準(zhǔn)備都提前完成，確保后面100%成功提交事務(wù)。如果準(zhǔn)備工作失敗，則及時(shí)通知TM。
② 真正提交階段。在該階段，TM將基于第1階段的投票結(jié)果進(jìn)行決策，決定提交或者取消事務(wù)。當(dāng)且僅當(dāng)所有的RM都同意提交時(shí)，TM才通知所有RM正式提交，否則TM將通知所有RM取消事務(wù)。操作流程如下圖所示：
兩階段提交的精妙之處在于，它充分考慮了分布式系統(tǒng)的不可靠因素，并采用非常簡單的方式，將導(dǎo)致事務(wù)提交失敗的概率降到最小。下面給出一個(gè)形象的解釋過程，來說明二階段提交時(shí)如何做到這一點(diǎn)的：
假如一個(gè)事務(wù)的提交過程總共需要30秒，其中Prepare階段需要花費(fèi)28秒，真正的commit階段只需要花費(fèi)2秒，那么Commit階段發(fā)生錯(cuò)誤的概率與Prepare階段相比，只是2/28(7.14%)，也就是說如果Prepare階段成功了，這Commit階段失敗的概率就很小，從而增加了分布式事務(wù)執(zhí)行成功的概率。
但是二階段提交也有明顯的缺點(diǎn)，在實(shí)際應(yīng)用中使用較少。主要原因如下：
- XA事務(wù)的介入增加了TM中間件，使系統(tǒng)變得更復(fù)雜了，而且大部分TM中間件都是收費(fèi)的。
- XA事務(wù)應(yīng)為增加了TM，導(dǎo)致其性能并不高。
3 互聯(lián)網(wǎng)中分布式事務(wù)解決方案
互聯(lián)網(wǎng)領(lǐng)域有幾種流行的分布式解決方案，但未形成像X/OpenDTP那樣標(biāo)準(zhǔn)的工業(yè)規(guī)范。常用的解決方案如下：
解決方案1：業(yè)務(wù)接口整合，避免分布式事務(wù)；
解決方案2：最終一致性方法，eBay模式；
解決方案3：X/OpenDTP模式的支付寶的DTS方案；
