現(xiàn)在提起分布式事務(wù)中的“事務(wù)”迫皱，和傳統(tǒng)的數(shù)據(jù)庫事務(wù)中的“事務(wù)”嚴(yán)格意義上已經(jīng)不是完全等同的了歉闰。
設(shè)計一個分布式事務(wù)框架前，首先要明確問題到定義舍杜。
分析具體應(yīng)用場景，包括以下三個：A赵辕、服務(wù)內(nèi)跨數(shù)據(jù)庫的事務(wù)既绩；B、跨內(nèi)部服務(wù)的事務(wù)还惠；C饲握、跨外部服務(wù)的事務(wù)。
其中劃分內(nèi)部和外部的標(biāo)準(zhǔn)是：內(nèi)部服務(wù)我們可以控制其實現(xiàn)蚕键，修改配置或代碼救欧；外部服務(wù)指的是第三方的，只能約定通信的方式和具體協(xié)議锣光，具體代碼實現(xiàn)在控制范圍之外笆怠。
具體如下：
應(yīng)用場景A：服務(wù)內(nèi)跨數(shù)據(jù)庫
如下圖所示，在同一個服務(wù)方法內(nèi)誊爹，訪問兩個或兩個以上數(shù)據(jù)庫蹬刷。
我們知道，Java事務(wù)是通過Connection對象控制的频丘。不同的數(shù)據(jù)庫办成，是不同的數(shù)據(jù)庫鏈接，通過不同的Connection對象實現(xiàn)搂漠。傳統(tǒng)數(shù)據(jù)庫事務(wù)無法實現(xiàn)事務(wù)控制盯另，需要引入事務(wù)協(xié)調(diào)者的概念晶府。這是場景A，這個場景中分布式體現(xiàn)在數(shù)據(jù)庫的部署上。
應(yīng)用場景B：跨內(nèi)部服務(wù)
如下圖所示格郁，一個服務(wù)通過微服務(wù)框架或者RPC調(diào)用調(diào)用其他的服務(wù)，多個子服務(wù)需要同時成功或失敗狈究。每個子服務(wù)都有自己的持久化方式煤裙，不一定是數(shù)據(jù)庫，體現(xiàn)事務(wù)的持久性馆截。每個子服務(wù)部署在不同的服務(wù)容器中充活，不同的服務(wù)容器部署在不同的服務(wù)器節(jié)點上蜂莉。這是場景B，這個場景中分布式體現(xiàn)在服務(wù)（或應(yīng)用）的部署上混卵。
這時候映穗，事務(wù)的概念已經(jīng)超出“數(shù)據(jù)庫”的范疇了。
應(yīng)用場景C：跨外部服務(wù)
這個場景是在應(yīng)用場景B的基礎(chǔ)上幕随，進一步蚁滋，服務(wù)的具體實現(xiàn)在我們控制范圍之外。我們不能限制其實現(xiàn)語言赘淮，不能要求指定方法上加標(biāo)注（注解）辕录。甚至除了服務(wù)調(diào)用的網(wǎng)絡(luò)通道外，我們不能期望服務(wù)間訪問相同的Zookeeper作為事務(wù)協(xié)調(diào)器梢卸。這是場景C走诞，這個場景中，我們只能在通信協(xié)議層面做約定蛤高，是最徹底的分布式場景蚣旱。
小結(jié)
以上分析了分布式事務(wù)的三個應(yīng)用場景，具體的技術(shù)方案也針對這三個場景做設(shè)計戴陡。
