不久之前團(tuán)隊(duì)有個(gè)新人問(wèn)我一個(gè)很重要的web服務(wù)接口如何保證事務(wù)的問(wèn)題。因?yàn)樯婕暗娇鐜?kù)事務(wù)，當(dāng)時(shí)我只是回答目前我們的SOA框架都不支持跨庫(kù)事務(wù)。然后就問(wèn)到了數(shù)據(jù)庫(kù)跨庫(kù)事務(wù)是如何實(shí)現(xiàn)的，我只能憑印象含糊回答多數(shù)是基于數(shù)據(jù)庫(kù)日志（后來(lái)知道就是所謂的預(yù)寫(xiě)日志W(wǎng)rite-Ahead Logging），具體數(shù)據(jù)庫(kù)內(nèi)部如何控制數(shù)據(jù)一致性則真的說(shuō)不清楚。后來(lái)一起查了一下事務(wù)的資料，原來(lái)DB的事務(wù)控制除了基于預(yù)寫(xiě)日志還要實(shí)現(xiàn)兩階段提交協(xié)議（2PC），參考MSDN摘抄兩段加深印象。

When the transaction manager receives a commit request, it sends a prepare command to all of the resource managers involved in the transaction. Each resource manager then does everything required to make the transaction durable, and all buffers holding log images for the transaction are flushed to disk. As each resource manager completes the prepare phase, it returns success or failure of the prepare to the transaction manager.

If the transaction manager receives successful prepares from all of the resource managers, it sends commit commands to each resource manager. The resource managers can then complete the commit. If all of the resource managers report a successful commit, the transaction manager then sends a success notification to the application. If any resource manager reported a failure to prepare, the transaction manager sends a rollback command to each resource manager and indicates the failure of the commit to the application.

如何理解2PC實(shí)現(xiàn)分布式事務(wù)的呢？下面舉例說(shuō)明下。

假設(shè)有A、B、C三個(gè)數(shù)據(jù)庫(kù)，A作為一個(gè)事務(wù)發(fā)起者，稱(chēng)為“主庫(kù)”，B和C則稱(chēng)為”從庫(kù)”。假設(shè)需要執(zhí)行一個(gè)在A、B和C三個(gè)庫(kù)的某個(gè)表中插入一行數(shù)據(jù)的事務(wù)。

準(zhǔn)備階段（Prepare Phase），A鎖定表，并將事務(wù)寫(xiě)入自己的預(yù)寫(xiě)日志；A將事務(wù)發(fā)給從庫(kù)B和C，B和C也各自鎖定自己的表，并把事務(wù)寫(xiě)入預(yù)寫(xiě)日志，完成后返回告訴A準(zhǔn)備階段完成；提交階段（Commit Phase），A開(kāi)始執(zhí)行自己的事務(wù)，并通知B和C提交事務(wù)。如果在這個(gè)過(guò)程中沒(méi)有任何錯(cuò)誤，那么操作將在A、B和C庫(kù)中完成；如果發(fā)生錯(cuò)誤，比如從庫(kù)C超時(shí)無(wú)響應(yīng)，或者從庫(kù)C磁盤(pán)空間不足…A將通知所有參與事務(wù)的B和C回滾該事務(wù)，并且回滾A自己的事務(wù)。

順便重點(diǎn)再提一下預(yù)寫(xiě)日志，因?yàn)閿?shù)據(jù)庫(kù)的這種日志無(wú)比重要，普通的增刪改查、數(shù)據(jù)還原、單庫(kù)事務(wù)以及本文的分布式事務(wù)都離不開(kāi)它，沒(méi)有它絕大多數(shù)主流數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性根本無(wú)法實(shí)現(xiàn)。

到這里大家應(yīng)該已經(jīng)看到，相比單庫(kù)事務(wù)，分布式事務(wù)控制更加復(fù)雜，而且開(kāi)銷(xiāo)極大。雖然一些高級(jí)開(kāi)發(fā)框架如.net framework提供了較為強(qiáng)大豐富的類(lèi)庫(kù)如TransactionScope來(lái)簡(jiǎn)化開(kāi)發(fā)分布式事務(wù)，但是建議能不用則不用，因?yàn)樗环从称毡榇嬖谛阅軉?wèn)題和無(wú)意識(shí)的死鎖問(wèn)題。這種分布式事務(wù)的場(chǎng)景如果頻繁出現(xiàn)，重新拆分系統(tǒng)合理規(guī)劃架構(gòu)才是正道。

總結(jié)：在大型web應(yīng)用中如何保持事務(wù)這個(gè)話題被問(wèn)得非常多，個(gè)人已經(jīng)是不止一次被問(wèn)到所維護(hù)的站點(diǎn)是如何實(shí)現(xiàn)事務(wù)的。在分布式多集群環(huán)境下，業(yè)務(wù)邏輯錯(cuò)綜復(fù)雜，保證數(shù)據(jù)庫(kù)完全可靠存儲(chǔ)當(dāng)然并不容易。但是web應(yīng)用程序的一個(gè)典型特點(diǎn)是讀多寫(xiě)少，犧牲極少的數(shù)據(jù)一致性獲得系統(tǒng)的高可擴(kuò)展性可維護(hù)性以及高性能，那么一點(diǎn)點(diǎn)的數(shù)據(jù)不準(zhǔn)確在業(yè)務(wù)上完全可以容忍，何況我們有日志，后續(xù)還有很多補(bǔ)償措施，甚至直接人工介入處理也未嘗不可。

參考：

http://msdn.microsoft.com/en-us/library/ms191440.aspx

http://technet.microsoft.com/zh-cn/library/ms186259(v=SQL.105).aspx

http://www.cnblogs.com/CareySon/archive/2012/02/13/2349751.html

http://www.cnblogs.com/CareySon/archive/2012/02/14/2351149.html