系統(tǒng)經(jīng)sharding改造之后，原來單一的數(shù)據(jù)庫(kù)會(huì)演變成多個(gè)數(shù)據(jù)庫(kù)，如何確保多數(shù)據(jù)源同時(shí)操作的原子性和一致性是不得不考慮的一個(gè)問題?？傮w上看，目前對(duì)于一個(gè)分布式系統(tǒng)的事務(wù)處理有三種方式：分布式事務(wù)、基于Best Efforts 1PC模式的事務(wù)以及事務(wù)補(bǔ)償機(jī)制。我們下面對(duì)這三種處理方式一一進(jìn)行分析。

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的岳塘網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

分布式事務(wù)

這是最為人們所熟知的多數(shù)據(jù)源事務(wù)處理機(jī)制。本文并不打算對(duì)分布式事務(wù)做過多介紹，讀者可參考此文：關(guān)于分布式事務(wù)、兩階段提交、一階段提交、Best Efforts 1PC模式和事務(wù)補(bǔ)償機(jī)制的研究 。在這里只想對(duì)分布式事務(wù)的利弊作一下分析。

優(yōu)勢(shì)：

1. 基于兩階段提交，***限度地保證了跨數(shù)據(jù)庫(kù)操作的“原子性”，是分布式系統(tǒng)下最嚴(yán)格的事務(wù)實(shí)現(xiàn)方式。

2. 實(shí)現(xiàn)簡(jiǎn)單，工作量小。由于多數(shù)應(yīng)用服務(wù)器以及一些獨(dú)立的分布式事務(wù)協(xié)調(diào)器做了大量的封裝工作，使得項(xiàng)目中引入分布式事務(wù)的難度和工作量基本上可以忽略不計(jì)。

劣勢(shì)：

系統(tǒng)“水平”伸縮的死敵?；趦呻A段提交的分布式事務(wù)在提交事務(wù)時(shí)需要在多個(gè)節(jié)點(diǎn)之間進(jìn)行協(xié)調(diào),***限度地推后了提交事務(wù)的時(shí)間點(diǎn)，客觀上延長(zhǎng)了事務(wù)的執(zhí)行時(shí)間，這會(huì)導(dǎo)致事務(wù)在訪問共享資源時(shí)發(fā)生沖突和死鎖的概率增高，隨著數(shù)據(jù)庫(kù)節(jié)點(diǎn)的增多，這種趨勢(shì)會(huì)越來越嚴(yán)重，從而成為系統(tǒng)在數(shù)據(jù)庫(kù)層面上水平伸縮的”枷鎖”， 這是很多Sharding系統(tǒng)不采用分布式事務(wù)的主要原因。

基于Best Efforts 1PC模式的事務(wù)

與分布式事務(wù)采用的兩階段提交不同，Best Efforts 1PC模式采用的是一階段端提交，犧牲了事務(wù)在某些特殊情況(當(dāng)機(jī)、網(wǎng)絡(luò)中斷等)下的安全性，卻獲得了良好的性能，特別是消除了對(duì)水平伸縮的桎酷。Distributed transactions in Spring, with and without XA一文對(duì)Best Efforts 1PC模式進(jìn)行了詳細(xì)的說明，該文提供的Demo代碼更是直接給出了在Spring環(huán)境下實(shí)現(xiàn)一階段提交的多數(shù)據(jù)源事務(wù)管理示例。不過需要注意的是，原示例是基于spring 3.0之前的版本，如果你使用spring 3.0+,會(huì)得到如下錯(cuò)誤：java.lang.IllegalStateException: Cannot activate transaction synchronization – already active，如果使用spring 3.0+，你需要參考spring-data-neo4j的實(shí)現(xiàn)。鑒于Best Efforts 1PC模式的性能優(yōu)勢(shì)，以及相對(duì)簡(jiǎn)單的實(shí)現(xiàn)方式，它被大多數(shù)的sharding框架和項(xiàng)目采用。

事務(wù)補(bǔ)償機(jī)制

對(duì)于那些對(duì)性能要求很高，但對(duì)一致性要求并不高的系統(tǒng)，往往并不苛求系統(tǒng)的實(shí)時(shí)一致性，只要在一個(gè)允許的時(shí)間周期內(nèi)達(dá)到最終一致性即可，這使得事務(wù)補(bǔ)償機(jī)制成為一種可行的方案。事務(wù)補(bǔ)償機(jī)制最初被提出是在“長(zhǎng)事務(wù)”的處理中，但是對(duì)于分布式系統(tǒng)確保一致性也有很好的參考意義?；\統(tǒng)地講，與事務(wù)在執(zhí)行中發(fā)生錯(cuò)誤后立即回滾的方式不同，事務(wù)補(bǔ)償是一種事后檢查并補(bǔ)救的措施，它只期望在一個(gè)容許時(shí)間周期內(nèi)得到最終一致的結(jié)果就可以了。事務(wù)補(bǔ)償?shù)膶?shí)現(xiàn)與系統(tǒng)業(yè)務(wù)緊密相關(guān)，并沒有一種標(biāo)準(zhǔn)的處理方式。一些常見的實(shí)現(xiàn)方式有：對(duì)數(shù)據(jù)進(jìn)行對(duì)帳檢查;基于日志進(jìn)行比對(duì);定期同標(biāo)準(zhǔn)數(shù)據(jù)來源進(jìn)行同步，等等。

小結(jié)

分布式事務(wù)，最嚴(yán)格的事務(wù)實(shí)現(xiàn)，但性能是個(gè)大問題;Best Efforts 1PC模式，性能與事務(wù)可靠性的平衡，支持系統(tǒng)水平伸縮，大多數(shù)情況下是最合適的選擇;事務(wù)補(bǔ)償機(jī)制，只能適用于對(duì)事務(wù)性要求不高，允許數(shù)據(jù)“最終一致”即可的系統(tǒng)，犧牲實(shí)時(shí)一致性，獲得***的性能回報(bào)。

網(wǎng)站標(biāo)題：DB分庫(kù)分表（4）：多數(shù)據(jù)源的事務(wù)處理
瀏覽路徑：http://uogjgqi.cn/article/coedhjp.html