一、提交代碼寫到一起

例如：

C# code

?

1

2

3

4

5

6

7

8

9

10

using(varconn1=reateConnection(str1))

using(varconn2=CreateConnetion(str2))

using(varconn3=CreateConnetion(str3))

{

..............................

..............................

conn1.Commit();

conn2.Commit();

conn3.Commit();

}

這樣Commit階段都是簡(jiǎn)單地信號(hào)，之前都已經(jīng)更改了數(shù)據(jù)庫(kù)事務(wù)日志數(shù)據(jù)，只是還沒有提交而已，同時(shí)失敗的可能性會(huì)比較小。這種方案不是正規(guī)解決方案，只是說失敗的可能性減小了。

二：設(shè)計(jì)“自動(dòng)撤回、沖銷”流程，并且為每一個(gè)分事務(wù)動(dòng)做都寫一個(gè)額外的“確認(rèn)”步驟。

當(dāng)執(zhí)行確認(rèn)時(shí)，校驗(yàn)當(dāng)前進(jìn)程隨機(jī)會(huì)話編號(hào)，如果事務(wù)發(fā)生會(huì)話的編號(hào)跟確認(rèn)會(huì)話編號(hào)一致則記錄確認(rèn)成功，如果不一致（例如進(jìn)程失敗而重啟了）則執(zhí)行沖銷流程。

這種方案是正規(guī)的“最終一致性”解決方案。最終一致性是業(yè)務(wù)方案，業(yè)務(wù)就是這么明確的——任何業(yè)務(wù)都需要異步確認(rèn)一遍，確認(rèn)時(shí)判斷當(dāng)前進(jìn)程會(huì)話編號(hào)跟業(yè)務(wù)發(fā)生時(shí)的進(jìn)程會(huì)話編號(hào)是否一致。

在比較現(xiàn)代的高性能系統(tǒng)中，實(shí)際上講究的通常是“最終一致性”而不是純技術(shù)的一致性。所以糾結(jié)數(shù)據(jù)庫(kù)事務(wù)保護(hù)，可以看作是性能殺手，是不了解大數(shù)據(jù)平臺(tái)編程設(shè)計(jì)的，流程設(shè)計(jì)傾向于高并發(fā)電信級(jí)處理理念，跟那種入門者喜好“數(shù)據(jù)庫(kù)事務(wù)技術(shù)”是根本相反的算法選擇??！所以在程序上是負(fù)載均衡、真正分布式的。干某件事情的進(jìn)程負(fù)責(zé)異步地確認(rèn)任務(wù)，否則假設(shè)進(jìn)程失敗了、或者事務(wù)超時(shí)了（例如5秒鐘還沒有完成事務(wù)），不得不由其它進(jìn)程事后處理，就開啟業(yè)務(wù)數(shù)據(jù)沖銷動(dòng)做了。