建站
咨詢
售后
建站咨詢
新聞中心
系統(tǒng)經(jīng)sharding改造之后，原來單一的數(shù)據(jù)庫會演變成多個數(shù)據(jù)庫，如何確保多數(shù)據(jù)源同時操作的原子性和一致性是不得不考慮的一個問題?？傮w上看，目前對于一個分布式系統(tǒng)的事務(wù)處理有三種方式：分布式事務(wù)、基于Best Efforts 1PC模式的事務(wù)以及事務(wù)補(bǔ)償機(jī)制。我們下面對這三種處理方式一一進(jìn)行分析。
創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計制作、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的岳塘網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
分布式事務(wù)
這是最為人們所熟知的多數(shù)據(jù)源事務(wù)處理機(jī)制。本文并不打算對分布式事務(wù)做過多介紹，讀者可參考此文：關(guān)于分布式事務(wù)、兩階段提交、一階段提交、Best Efforts 1PC模式和事務(wù)補(bǔ)償機(jī)制的研究 。在這里只想對分布式事務(wù)的利弊作一下分析。
優(yōu)勢：
1. 基于兩階段提交，***限度地保證了跨數(shù)據(jù)庫操作的“原子性”，是分布式系統(tǒng)下最嚴(yán)格的事務(wù)實(shí)現(xiàn)方式。
2. 實(shí)現(xiàn)簡單，工作量小。由于多數(shù)應(yīng)用服務(wù)器以及一些獨(dú)立的分布式事務(wù)協(xié)調(diào)器做了大量的封裝工作，使得項(xiàng)目中引入分布式事務(wù)的難度和工作量基本上可以忽略不計。
劣勢：
系統(tǒng)“水平”伸縮的死敵?；趦呻A段提交的分布式事務(wù)在提交事務(wù)時需要在多個節(jié)點(diǎn)之間進(jìn)行協(xié)調(diào),***限度地推后了提交事務(wù)的時間點(diǎn)，客觀上延長了事務(wù)的執(zhí)行時間，這會導(dǎo)致事務(wù)在訪問共享資源時發(fā)生沖突和死鎖的概率增高，隨著數(shù)據(jù)庫節(jié)點(diǎn)的增多，這種趨勢會越來越嚴(yán)重，從而成為系統(tǒng)在數(shù)據(jù)庫層面上水平伸縮的”枷鎖”， 這是很多Sharding系統(tǒng)不采用分布式事務(wù)的主要原因。
基于Best Efforts 1PC模式的事務(wù)
與分布式事務(wù)采用的兩階段提交不同，Best Efforts 1PC模式采用的是一階段端提交，犧牲了事務(wù)在某些特殊情況(當(dāng)機(jī)、網(wǎng)絡(luò)中斷等)下的安全性，卻獲得了良好的性能，特別是消除了對水平伸縮的桎酷。Distributed transactions in Spring, with and without XA一文對Best Efforts 1PC模式進(jìn)行了詳細(xì)的說明，該文提供的Demo代碼更是直接給出了在Spring環(huán)境下實(shí)現(xiàn)一階段提交的多數(shù)據(jù)源事務(wù)管理示例。不過需要注意的是，原示例是基于spring 3.0之前的版本，如果你使用spring 3.0+,會得到如下錯誤：java.lang.IllegalStateException: Cannot activate transaction synchronization – already active，如果使用spring 3.0+，你需要參考spring-data-neo4j的實(shí)現(xiàn)。鑒于Best Efforts 1PC模式的性能優(yōu)勢，以及相對簡單的實(shí)現(xiàn)方式，它被大多數(shù)的sharding框架和項(xiàng)目采用。
事務(wù)補(bǔ)償機(jī)制
對于那些對性能要求很高，但對一致性要求并不高的系統(tǒng)，往往并不苛求系統(tǒng)的實(shí)時一致性，只要在一個允許的時間周期內(nèi)達(dá)到最終一致性即可，這使得事務(wù)補(bǔ)償機(jī)制成為一種可行的方案。事務(wù)補(bǔ)償機(jī)制最初被提出是在“長事務(wù)”的處理中，但是對于分布式系統(tǒng)確保一致性也有很好的參考意義。籠統(tǒng)地講，與事務(wù)在執(zhí)行中發(fā)生錯誤后立即回滾的方式不同，事務(wù)補(bǔ)償是一種事后檢查并補(bǔ)救的措施，它只期望在一個容許時間周期內(nèi)得到最終一致的結(jié)果就可以了。事務(wù)補(bǔ)償?shù)膶?shí)現(xiàn)與系統(tǒng)業(yè)務(wù)緊密相關(guān)，并沒有一種標(biāo)準(zhǔn)的處理方式。一些常見的實(shí)現(xiàn)方式有：對數(shù)據(jù)進(jìn)行對帳檢查;基于日志進(jìn)行比對;定期同標(biāo)準(zhǔn)數(shù)據(jù)來源進(jìn)行同步，等等。
小結(jié)
分布式事務(wù)，最嚴(yán)格的事務(wù)實(shí)現(xiàn)，但性能是個大問題;Best Efforts 1PC模式，性能與事務(wù)可靠性的平衡，支持系統(tǒng)水平伸縮，大多數(shù)情況下是最合適的選擇;事務(wù)補(bǔ)償機(jī)制，只能適用于對事務(wù)性要求不高，允許數(shù)據(jù)“最終一致”即可的系統(tǒng)，犧牲實(shí)時一致性，獲得***的性能回報。
本文題目：DB分庫分表（4）：多數(shù)據(jù)源的事務(wù)處理
文章分享：http://fisionsoft.com.cn/article/coedhjp.html
