在上一篇博客里墅诡，<a href="http://www.reibang.com/p/e9004c0db5cc">分布式事務(wù)系統(tǒng)設(shè)計(jì)</a>，主要是從中間件的角度去考慮如何實(shí)現(xiàn)一個(gè)分布式事務(wù)的中間件席爽，文章只寫了一個(gè)大概的設(shè)計(jì)，詳細(xì)并沒有寫出來啊片；
根據(jù)業(yè)務(wù)場景不同只锻，系統(tǒng)定義了多種事務(wù)模式，主要包括標(biāo)準(zhǔn)模式紫谷、自定義模式齐饮。每種事務(wù)模式對(duì)應(yīng)了自己的RM實(shí)現(xiàn)。當(dāng)有新的事務(wù)模式需求出現(xiàn)笤昨，我們可以開發(fā)一個(gè)新的滿足新的分布式事務(wù)通信協(xié)議的RM祖驱。
一個(gè)分布式事務(wù)中間件大概應(yīng)該存在兩種模式：
標(biāo)準(zhǔn)模式
讀未提交(read uncommitted)和讀已提交(read committed)，其中讀未提交是缺省設(shè)置
Read uncommitted
標(biāo)準(zhǔn)模式在讀未提交的隔離級(jí)別下瞒窒，存在臟寫捺僻，臟讀的風(fēng)險(xiǎn)。
臟寫出現(xiàn)的概率很低根竿，只有以下幾個(gè)條件同時(shí)滿足才會(huì)出現(xiàn)：
A） 事務(wù)1修改了T表的一行記錄陵像；
B） 事務(wù)2接著也修改了T表的同一行記錄就珠；
C） 事務(wù)1因?yàn)槟撤N原因需要回滾
上面3個(gè)條件同時(shí)滿足時(shí)，事務(wù)1回滾失敗醒颖，出現(xiàn)臟寫情況妻怎，這時(shí)事務(wù)系統(tǒng)告警模塊會(huì)通知到業(yè)務(wù)人員，需要根據(jù)系統(tǒng)的Undo日志進(jìn)行恢復(fù)泞歉。為什么說發(fā)生概率很低逼侦？一個(gè)分布式事務(wù)完成時(shí)間通常是毫秒級(jí)，兩個(gè)分布式事務(wù)在這么短時(shí)間內(nèi)并發(fā)修改同一行記錄概率很低腰耙，假設(shè)萬分之一榛丢；事務(wù)失敗的概率假設(shè)也是萬分之一，則出現(xiàn)臟寫的概率是億分之一挺庞，可以說概率非常低了晰赞。
臟寫出現(xiàn)概率極低，即使出現(xiàn)选侨，由于在業(yè)務(wù)庫上記錄了詳細(xì)的undo/redo log掖鱼，手工恢復(fù)代價(jià)也通常較小援制；所以臟寫問題對(duì)絕大多數(shù)應(yīng)用場景的負(fù)面影響可以忽略戏挡，建議采用這種讀未提交的隔離級(jí)別，比讀已提交級(jí)別有更好的性能晨仑。
臟讀指用戶讀到了分布式事務(wù)的中間狀態(tài)褐墅。對(duì)于成功的分布式事務(wù)，這種中間狀態(tài)基本可以認(rèn)為是沒有負(fù)面影響的洪己；對(duì)于失敗的分布式事務(wù)妥凳，也只有很少的場景下會(huì)有負(fù)面影響，因?yàn)檫@種中間狀態(tài)持續(xù)時(shí)間很短（通常是毫秒級(jí)）码泛，用戶很難感知猾封。即使用戶看到了中間狀態(tài)，通常也是能夠理解的噪珊，因?yàn)樗雷约菏聞?wù)失敗了晌缘。
標(biāo)準(zhǔn)模式的“讀未提交”隔離級(jí)別是的主流應(yīng)用，它兼顧了易用性與較高的性能痢站，適用于多數(shù)分布式事務(wù)場景Read committed
標(biāo)準(zhǔn)模式在讀已提交的隔離級(jí)別下磷箕，將對(duì)所管理的所有讀已提交的分布式事務(wù)，進(jìn)行寫入記錄的行級(jí)鎖檢查阵难，當(dāng)發(fā)現(xiàn)鎖沖突岳枷，采用重試策略（最長550ms），如果經(jīng)過重試后還是拿不到鎖，將拒絕后進(jìn)的事務(wù)空繁，并將異常拋出給上層業(yè)務(wù)系統(tǒng)殿衰。
需要說明的是：僅能保證被管理的讀已提交的事務(wù)間的Read Committed的隔離性。
隔離級(jí)別可以通過的RM配置項(xiàng)進(jìn)行設(shè)置盛泡。
讀已提交隔離級(jí)別比讀未提交增大了開銷（10%～20%）闷祥，如果select語句也采用讀已提交則會(huì)有更大開銷。如4.1.1所分析傲诵，實(shí)際業(yè)務(wù)場景下凯砍，讀未提交是足夠安全的，不建議使用讀已提交隔離級(jí)別拴竹。
自定義模式
自定義模式就是業(yè)界比較流行的Tcc模式
TCC分別對(duì)應(yīng)Try/Prepare悟衩、Confirm/Commit和Cancel/Rollback三種操作，這三種操作的業(yè)務(wù)含義如下
- Try/Prepare：預(yù)留業(yè)務(wù)資源
- Confirm/Commit：確認(rèn)執(zhí)行業(yè)務(wù)操作
- Cancel/Rollback：取消執(zhí)行業(yè)務(wù)操作
這種模式的話栓拜，不依賴于事務(wù)系統(tǒng)去推進(jìn)各資源管理器去推進(jìn)各分支更新事務(wù)狀態(tài)
優(yōu)點(diǎn)：
- 解決了跨應(yīng)用業(yè)務(wù)操作的原子性問題座泳，在諸如組合支付、賬務(wù)拆分場景非常實(shí)用菱属。
- TCC實(shí)際上把數(shù)據(jù)庫層的二階段提交上提到了應(yīng)用層來實(shí)現(xiàn)钳榨，對(duì)于數(shù)據(jù)庫來說是一階段提交，規(guī)避了數(shù)據(jù)庫層的2PC性能低下問題纽门。
缺點(diǎn): - TCC的Try、Confirm和Cancel操作功能需業(yè)務(wù)提供营罢，開發(fā)成本很高
