Alwayson是微軟從SQL2012開始引入的一種高可用和高性能架構(gòu)，它既可以實(shí)現(xiàn)故障轉(zhuǎn)移，同時(shí)又能實(shí)現(xiàn)查詢分離，是當(dāng)前SQL server的所有架構(gòu)中最優(yōu)秀的一種。

因此，一般我們都會(huì)推薦使用AlwaysON來(lái)部署生產(chǎn)數(shù)據(jù)庫(kù)，不過(guò)，盡管AlwaysON的優(yōu)勢(shì)非常明顯，但并非適應(yīng)于所有的業(yè)務(wù)場(chǎng)景。

分布式事務(wù)是指通過(guò)分布式事務(wù)協(xié)調(diào)器（MSDTC）的統(tǒng)一控制、將事務(wù)中的每個(gè)操作分解到多臺(tái)主機(jī)上分別執(zhí)行、每臺(tái)主機(jī)執(zhí)行成功后整個(gè)事務(wù)才能提交的事務(wù)，分布式事務(wù)協(xié)調(diào)器用來(lái)保證數(shù)據(jù)的一致性。跨數(shù)據(jù)庫(kù)事務(wù)與此類似，只是不會(huì)用到MSDTC，而是將DBID最小的一個(gè)作為分布式事務(wù)協(xié)調(diào)器。

如果在一個(gè)分布式事務(wù)執(zhí)行期間AlwaysON發(fā)生了故障轉(zhuǎn)移，AG服務(wù)從主副本轉(zhuǎn)移到了輔助副本，分布式事務(wù)協(xié)調(diào)器因?yàn)槭詹坏皆鞲北镜氖聞?wù)提交確認(rèn)信息，認(rèn)為事務(wù)執(zhí)行失敗，然后將其他參與（分布式事務(wù)的）節(jié)點(diǎn)上的應(yīng)要提交的事務(wù)回滾。對(duì)于新的主副本，因?yàn)闆](méi)有參與之前的分布式事務(wù)，因此無(wú)法從分布式事務(wù)協(xié)調(diào)器獲取事務(wù)的狀態(tài)，繼續(xù)維持現(xiàn)有的數(shù)據(jù)不變化，從而導(dǎo)致新副本與參與分布式事務(wù)的其他節(jié)點(diǎn)上的數(shù)據(jù)不一致。

備注：跨數(shù)據(jù)庫(kù)事務(wù)的原因與此類似。

下面我們通過(guò)圖例來(lái)展示這個(gè)過(guò)程：

下圖：假設(shè)有ABC三個(gè)節(jié)點(diǎn)，AC之間做了AlwaysON，其中A.table1中a的初始值為0，B.table1中a的初始值為1000。有一個(gè)分布式事務(wù)1，需要將節(jié)點(diǎn)A的表中a加上1000，同時(shí)需要在節(jié)點(diǎn)B的表中a減去1000。

BEGIN TRAN Update A.table1 set a=a+1000 ; Update B.table1 set a=a-1000 ; COMMIT TRAN 

正常情況下，最后的結(jié)果應(yīng)該是A.table1.a=1000，B.table1.a=0,，C.table1.a=1000。

現(xiàn)在有這樣一個(gè)場(chǎng)景，A和B都已經(jīng)commit，A.table1.a=1000，B.table1.a=0，且A已經(jīng)將事務(wù)1的操作通過(guò)日志同步到了主機(jī)C，C.table1.a=1000。

正常情況下，主機(jī)A和B都向事務(wù)協(xié)調(diào)器發(fā)送commit ack（提交確認(rèn)）信息，事務(wù)協(xié)調(diào)器收到兩者的確認(rèn)信息后就可以將整個(gè)事務(wù)標(biāo)記為提交。但現(xiàn)在A在發(fā)送commit ack信息時(shí)發(fā)生了宕機(jī)，分布式事務(wù)協(xié)調(diào)器只收到了主機(jī)B的commit ack，于是協(xié)調(diào)器將整個(gè)事務(wù)標(biāo)記為失敗，然后在主機(jī)B上回滾事務(wù)1的操作，此時(shí)B.table1.a=1000。

節(jié)點(diǎn)C雖然接管了AlwaysON集群，因?yàn)樗⒉皇欠植际绞聞?wù)的執(zhí)行者之一，所以它無(wú)法從分布式事務(wù)協(xié)調(diào)器獲取事務(wù)1的狀態(tài)，因此它不會(huì)回滾，a的值保持不變。最后C.table1.a=1000、B.table1.a=1000，發(fā)生了數(shù)據(jù)不一致的問(wèn)題。

參考文章：

http://blogs.msdn.com/b/alwaysonPRo/archive/2014/01/06/not-supported-ags-with-dtc-cross-database-transactions.aspx;

https://msdn.microsoft.com/en-us/library/ms366279(v=sql.110).aspx;

從上文可以看到，AlwaysON不支持分布式事務(wù)（和跨數(shù)據(jù)庫(kù)事務(wù)）的根本原因在于主副本故障轉(zhuǎn)移到輔助副本時(shí)會(huì)造成分布式事務(wù)執(zhí)行不一致。

解決這個(gè)問(wèn)題的焦點(diǎn)就是主副本和輔助副本的故障轉(zhuǎn)移。如果主副本與輔助副本之間不允許故障轉(zhuǎn)移（也就是處于異步同步模式下），輔助副本的職責(zé)只是接受來(lái)自主副本的日志，然后執(zhí)行redo實(shí)現(xiàn)同步，這樣一來(lái)就不會(huì)產(chǎn)生異常數(shù)據(jù)。

不過(guò)，主、輔副本無(wú)法故障轉(zhuǎn)移后，主副本存在單點(diǎn)故障的風(fēng)險(xiǎn)，為了避免此類情況發(fā)生，我們可以為主副本建立傳統(tǒng)的SQL Server故障轉(zhuǎn)移集群。在這種架構(gòu)下，如果主節(jié)點(diǎn)在執(zhí)行分布式事務(wù)發(fā)生了故障轉(zhuǎn)移，輔節(jié)點(diǎn)接管的SQL實(shí)例是原主節(jié)點(diǎn)的同一個(gè)實(shí)例，而且數(shù)據(jù)文件和日志文件是相同的，所以不會(huì)與其他參與分布式事務(wù)的節(jié)點(diǎn)產(chǎn)生數(shù)據(jù)不一致的問(wèn)題。