本文以一個(gè)實(shí)際業(yè)務(wù)問(wèn)題來(lái)談?wù)勈聞?wù)該如何處理。對(duì)接外部系統(tǒng)是是不可避免的，從廣泛意義上來(lái)說(shuō)，外部系統(tǒng)范圍很大，中間件（數(shù)據(jù)庫(kù)）也屬于外部系統(tǒng)。當(dāng)我們討論事務(wù)時(shí)，通常我們將那些沒(méi)有支持事務(wù)的系統(tǒng)稱(chēng)為外部系統(tǒng)，業(yè)務(wù)系統(tǒng)基本上都是外部系統(tǒng)。

問(wèn)題

有這樣一套系統(tǒng)，以gitlab為底層系統(tǒng)， 在gitlab project的基礎(chǔ)上封裝了代碼倉(cāng)，系統(tǒng)對(duì)其中一些與gitlab關(guān)聯(lián)的數(shù)據(jù)進(jìn)行了落表。創(chuàng)建代碼倉(cāng)的邏輯過(guò)程比較復(fù)雜，首先通過(guò)gitlab創(chuàng)建代碼倉(cāng)（其中返回的代碼倉(cāng)id需要落庫(kù)），系統(tǒng)表code_repo插入記錄，創(chuàng)建gitlabhook，系統(tǒng)表member插入記錄（維護(hù)系統(tǒng)用戶(hù)和對(duì)應(yīng)代碼倉(cāng)的關(guān)系），創(chuàng)建多個(gè)gitlabbranch(系統(tǒng)業(yè)務(wù)，初始化代碼倉(cāng)可以初始化多個(gè)分支)，系統(tǒng)表label插入記錄。

分析

以上大概說(shuō)明整個(gè)業(yè)務(wù)流程, gitlab接入的方式采用HTTP,不采用直接對(duì)接gitlab數(shù)據(jù)庫(kù)的原因是，其創(chuàng)建項(xiàng)目和分支業(yè)務(wù)邏輯復(fù)雜，梳理代價(jià)很大。對(duì)接任何系統(tǒng)其實(shí)本質(zhì)上可以概括為兩種：

,數(shù)據(jù)庫(kù)采用mysql。 在不考慮異常的情況，整個(gè)業(yè)務(wù)流程還是比較清晰的，但是分布式的核心就是處理各種異常情況，這也是分布式復(fù)雜的地方。因?yàn)榉植际降木W(wǎng)絡(luò)環(huán)境是很復(fù)雜的。我們很保證底層系統(tǒng)的可用性。在這里，當(dāng)gitlab其中的接口出現(xiàn)異常，系統(tǒng)仍落庫(kù)顯然是不合理的，同樣的當(dāng)數(shù)據(jù)庫(kù)發(fā)生異常，gitlab數(shù)據(jù)存在也是不合理的，分布式事務(wù)的核心要解決數(shù)據(jù)一致性。

解決還需要與當(dāng)前的項(xiàng)目架構(gòu)不能沖突。目前各服務(wù)還沒(méi)有拆分，運(yùn)行。數(shù)據(jù)庫(kù)也沒(méi)有拆分。其架構(gòu)仍是單體架構(gòu)模式，設(shè)計(jì)時(shí)考慮了后期的微服務(wù)拆分。目前主要問(wèn)題是解決Gitlab和DB之間的數(shù)據(jù)一致性，其復(fù)雜度沒(méi)有微服務(wù)多DB的高。

分布式事務(wù)（淺談）

事務(wù)的概念來(lái)自數(shù)據(jù)庫(kù)事務(wù)，在數(shù)據(jù)庫(kù)事務(wù)定義中，事務(wù)是一個(gè)執(zhí)行的邏輯單元，它需要提供一個(gè)一致、可靠的數(shù)據(jù)操作，它主要包括下面兩個(gè)目標(biāo)：

1. 當(dāng)出現(xiàn)任何錯(cuò)誤，包括系統(tǒng)宕機(jī)、部分失敗，都能保證左右的數(shù)據(jù)修改都能夠恢復(fù)到未修改的狀態(tài)；

2. 不通的事務(wù)并發(fā)處理相同的數(shù)據(jù)時(shí)，提供適當(dāng)?shù)母綦x機(jī)制。 我們常說(shuō)的ACID，其實(shí)是某些數(shù)據(jù)庫(kù)特有的事務(wù)實(shí)現(xiàn)方式，也就是實(shí)現(xiàn)了原子性、一致性、隔離性和持久性。 dan 分布式事務(wù)，一直是實(shí)現(xiàn)分布式系統(tǒng)過(guò)程中最大的挑戰(zhàn)，在單個(gè)數(shù)據(jù)源的系統(tǒng)中，只要該數(shù)據(jù)源支持事務(wù)，例如大部分關(guān)系型數(shù)據(jù)庫(kù)，一些MQ服務(wù)（redis,mysql,activeMQ等），我們實(shí)現(xiàn)事務(wù)相對(duì)容易。那么我們?nèi)绾卧诜植际较到y(tǒng)中實(shí)現(xiàn)事務(wù)呢？這就要從分布式系統(tǒng)的原則說(shuō)起，目前主要有BASE原理 ACP原理。其中ACP是：

3. A:可用性（Availability）

4. B:一致性（Consistency）

5. C:分區(qū)容錯(cuò)性（Tolerance of network Partition） ruan zhuang t愛(ài) A和P沒(méi)什么好說(shuō)的，就是分布式系統(tǒng)的基本特性，C（一致性）指在分布式系統(tǒng)中，多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)的一致性，包括一個(gè)節(jié)點(diǎn)修改的數(shù)據(jù)，通過(guò)另一個(gè)節(jié)點(diǎn)訪(fǎng)問(wèn)的時(shí)候也能夠看到；以及當(dāng)一個(gè)操作需要修改多個(gè)數(shù)據(jù)源的數(shù)據(jù)，多個(gè)修改都能夠同時(shí)完成或者同時(shí)不完成。

這里的一致性，我們可以看作是數(shù)據(jù)庫(kù)事務(wù)的ACID特性中，原子性、一致性甚至是隔離性的統(tǒng)一。如果以ACID標(biāo)準(zhǔn)實(shí)現(xiàn)分布式系統(tǒng)，在現(xiàn)實(shí)中是不可能的。其中原子性就沒(méi)法實(shí)現(xiàn)，如果一個(gè)業(yè)務(wù)請(qǐng)求，要修改多個(gè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)，那么這多個(gè)數(shù)據(jù)庫(kù)操作，就無(wú)法實(shí)現(xiàn)原子性，勢(shì)必會(huì)有一個(gè)先后，這一點(diǎn)點(diǎn)時(shí)間就違反了原子性。

所以，我們往往無(wú)法在分布式系統(tǒng)中實(shí)現(xiàn)完全的一致性，所以就有了BASE理論，BASE是BasicallAvailable（基本可用)，SOftstate(軟狀態(tài))和Eventually consistent(最終一致性)三個(gè)短語(yǔ)的縮寫(xiě)。BASE理論是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，要求實(shí)現(xiàn)最終一致性即可。

其中，SoftState（軟狀態(tài)）是指，在一個(gè)業(yè)務(wù)操作過(guò)程中，允許出現(xiàn)一個(gè)中間狀態(tài)，也就是軟狀態(tài)，而不是要求原子性那樣，要么完成要么不完成。例如在下單的時(shí)候，出現(xiàn)一個(gè)正在處理狀態(tài)。由于有這個(gè)軟狀態(tài)，那我的一致性就不是要求搶一致性，而是最終一致性，也就是說(shuō)，只要最終這個(gè)請(qǐng)求能夠處理完，所有數(shù)據(jù)狀態(tài)都是處理完的狀態(tài)；如果期間出錯(cuò)了，所有的數(shù)據(jù)也都一致，該失敗的失敗，該退錢(qián)的退錢(qián)，該重置的重置。 確定分布式系統(tǒng)的實(shí)現(xiàn)原則是最終一致性以后，同時(shí)也明確了我們實(shí)現(xiàn)分布式事務(wù)的原則，也是最終一致性。其實(shí)，不管數(shù)據(jù)庫(kù)事務(wù)的ACID特性，還是分布式事務(wù)的最終一致性，都是根據(jù)事務(wù)的定義和它的兩個(gè)目標(biāo)，所采用的不通的實(shí)現(xiàn)方式。

那我們?cè)撊绾螌?shí)現(xiàn)這個(gè)最終一致性呢？

單服務(wù)的分布式事務(wù)

首先，任何一個(gè)分布式系統(tǒng)，總是由一個(gè)個(gè)的系統(tǒng)組成，也就是一個(gè)個(gè)的服務(wù)，這些服務(wù)也可以部署多個(gè)實(shí)例。同時(shí)，我們整個(gè)系統(tǒng)也需要一定的方式相互通信。我們采用接口的方式，也可以通過(guò)MQ之類(lèi)的消息中間件通信。但是無(wú)論怎樣，分布式系統(tǒng)會(huì)涉及多個(gè)數(shù)據(jù)源。

對(duì)于這種每個(gè)服務(wù)訪(fǎng)問(wèn)多個(gè)數(shù)據(jù)源的情況，其實(shí)就是一個(gè)最簡(jiǎn)單的分布式事務(wù)的場(chǎng)景。如果大家在網(wǎng)上搜“Spring分布式事務(wù)實(shí)現(xiàn)”，搜索到結(jié)果也就是在說(shuō)這個(gè)場(chǎng)景下的分布式事務(wù)實(shí)現(xiàn)過(guò)程。要實(shí)現(xiàn)這個(gè)事務(wù)，首先需要對(duì)Spring的事務(wù)機(jī)制有一定的了解。對(duì)于這種情況，最簡(jiǎn)單的就是使用Springde JTA事務(wù)管理，但是我們知道。JTAs事務(wù)管理是通過(guò)兩階段提交實(shí)現(xiàn)的，在很多情況下，他的效率是很低的。因?yàn)樗诙鄠€(gè)數(shù)據(jù)源秀修改數(shù)據(jù)的時(shí)候，這些數(shù)據(jù)一直處在被鎖的狀態(tài)，直到多個(gè)數(shù)據(jù)源的事務(wù)都提交完成，才會(huì)釋放。

如果不用JTA,Spring也給我們提供了幾種方式，來(lái)近似的實(shí)現(xiàn)分布式事務(wù)，例如：

1. 事務(wù)同步，也就是提交一個(gè)事務(wù)的時(shí)候，通過(guò)Listener等方式通知另一個(gè)事務(wù)也提交。但是這種情況下，如果第二個(gè)事務(wù)提交出錯(cuò)了，第一個(gè)事務(wù)就無(wú)法回滾了，因?yàn)樗呀?jīng)提交完成了

2. 鏈?zhǔn)绞聞?wù)，也就是將多個(gè)事務(wù)，包裝在一個(gè)鏈?zhǔn)绞聞?wù)管理器中，當(dāng)提交事務(wù)的時(shí)候，一次提交里面的事務(wù)，對(duì)于這種情況，也存在上面所說(shuō)的問(wèn)題

所以，使用spring在單服務(wù)多數(shù)據(jù)源的情況下，實(shí)現(xiàn)分布式事務(wù)，實(shí)際上沒(méi)辦法完全實(shí)現(xiàn)事務(wù)的，因?yàn)槌鲥e(cuò)的時(shí)候不能夠保證。那么這時(shí)候，就需要通過(guò)其他機(jī)制來(lái)補(bǔ)充。比如重試，自己處理錯(cuò)誤和異常。
大家可以試想一下，分布式系統(tǒng)越復(fù)雜，它出錯(cuò)的情況就越多，我們需要考慮的補(bǔ)救措施就越多。這種修修補(bǔ)補(bǔ)的實(shí)現(xiàn)分布式事務(wù)的最終一致性的做法，始終不是一個(gè)好做法。但是，使用Spring解決單服務(wù)的分布式系統(tǒng)，始終是分布式事務(wù)實(shí)現(xiàn)的基礎(chǔ)。我們可以用其他的模式來(lái)方便我們解決分布式事務(wù)，但是在每個(gè)服務(wù)中，我們還是要經(jīng)常使用事務(wù)同步、鏈?zhǔn)绞聞?wù)等來(lái)實(shí)現(xiàn)事務(wù)。我們用Spring來(lái)保證絕大數(shù)情況下的事務(wù)問(wèn)題，而對(duì)于特殊的錯(cuò)誤情況，就采用其他的模式來(lái)解決。

分布式事務(wù)實(shí)現(xiàn)的模式

剛才說(shuō)了我們使用其他模式來(lái)處理分布式事務(wù)問(wèn)題，主要有下面五種模式，參考 分布式事務(wù)參考 ：

1. XA方案

2. TCC方案

3. 本地消息表

4. 可靠消息最終一直方案

5. 最大努力通知方案

解決

由于目前是單DB，可以盡最大限度利用單DB事務(wù)特性，Spring事務(wù)管理中介紹了有兩種事務(wù)管理方式（programmatically and declarative ）。 雖然官方文檔建議使用申明式事務(wù)管理方式，但是我們?cè)诨貪L數(shù)據(jù)庫(kù)事務(wù)需要執(zhí)行其他操作時(shí)，如API的反操作，手動(dòng)方式才能夠?qū)崿F(xiàn)。

CoderepoService中提供的創(chuàng)建代碼倉(cāng)接口createCodeRepo，主要包含①②③④操作，其中只有一個(gè)DB操作④，使用數(shù)據(jù)庫(kù)事務(wù)無(wú)法滿(mǎn)足情況。 例如當(dāng)①②執(zhí)行成功，③執(zhí)行失敗，這是通過(guò)異常事務(wù)回滾無(wú)法回滾Gitlab中的數(shù)據(jù)。所以必須手動(dòng)回滾，處理邏輯如下。我們Spring數(shù)據(jù)庫(kù)事務(wù)，保證DB操作， 當(dāng)③④失敗時(shí)手動(dòng)捕獲異常（回滾gitlab數(shù)據(jù)），并拋出系統(tǒng)業(yè)務(wù)異常（使事務(wù)生效）。

這里涉及的Gitlab操作對(duì)應(yīng)一個(gè)回滾操作deleteGitlabProject(),DB通過(guò)事務(wù)回滾。

總結(jié)

本文討論問(wèn)題類(lèi)似單服務(wù)多DB場(chǎng)景，不同的是gitlab數(shù)據(jù)與通是保證通過(guò)HTTP調(diào)用的,并沒(méi)有實(shí)現(xiàn)事務(wù)。 如何保證DB與第三方系統(tǒng)數(shù)據(jù)保持一致性的問(wèn)題，盡量較小的代碼改動(dòng)。在微服務(wù)多數(shù)據(jù)源的情況下不能夠滿(mǎn)足需求，需要根據(jù)業(yè)務(wù)選型。