當前位置:
首頁 > 知識 > Spring分散式事務實現概覽

Spring分散式事務實現概覽

分散式事務,一直是實現分散式系統過程中最大的挑戰。在只有單個數據源的單服務系統當中,只要這個數據源支持事務,例如大部分關係型資料庫,和一些MQ服務,如activeMQ等,我們就可以很容易的實現事務。

本地事物

大家可能都知道什麼是事務,但是我們還是再來看一下它的定義。事務的概念來自於資料庫事務,在資料庫事務定義中,事務是一個執行的邏輯單元,它需要提供一個一致、可靠的數據操作。它主要包括下面兩個目標:

當出現任何錯誤,包括系統宕機、部分失敗等,都能保證左右的數據修改都恢復到未修改的狀態。

不同的事務並發放完相同的數據時,提供適當的隔離機制。

我們常說的ACID其實,其實是某些資料庫特有的事務的實現方式,也就是實現了原子性、一致性、隔離性和持久性。

分散式系統的實現原則

那麼在分散式系統當中,我們應該怎麼樣去實現事務呢?這就需要從分散式系統的原則說起。分散式系統的實現原則有幾種說法,如BASE原理、ACP原理。

其中ACP是:

A: 可用性(Availability)

C: 一致性(Consistency)

P: 分區容錯性(Tolerance of network Partition)

A和P沒什麼好說的,就是分散式系統的基本特性,C(一致性)就是指在分散式系統當中,多個節點之間數據的一致性,包括一個節點修改的數據,通過另一個節點訪問的時候也能看到;以及當一個操作需要修改多個數據源的數據的時候,多個修改要都能夠完成,或者都不完成。

這裡的一致性,我們可以看做是上面說的資料庫事務的ACID特性中,原子性、一致性,甚至是隔離性的統一。如果以ACID這4個特性為要求來實現分散式系統,在現實當中是不可能的,其中原子性就沒有辦法實現。如果一個業務請求,要修改多個資料庫中的數據,那麼這多個資料庫的操作,就無法實現原子性,勢必會有一個先後,在第一個資料庫上完成以後,再在第二個資料庫上完成,那麼這期間的一點點時間,就違反了原子性。

所以,我們往往無法在分散式系統中實現完全的一致性,所以就有了BASE理論。BASE是Basically Available(基本可用)、Soft state(軟狀態)和Eventually consistent(最終一致性)三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果,要求實現最終一致性即可。

其中,Soft state(軟狀態)是指,在一個業務操作過程中,允許出現一個中間狀態,也就是軟狀態,而不要求原子性那樣,要麼都完成,要麼都不完成。例如在下單的時候,出現一個「正在處理」的狀態。由於有這個軟狀態,那我的一致性,就不要求是強一致性,而是最終一致性,也就是說,只要最終這個請求能處理完,所有的數據狀態都是處理完的狀態;如果期間出錯了,所有的數據也都一致,該失敗的失敗、該退錢的退錢、該重置的重置。

分散式事務的實現

所以,確定了分散式系統的實現原則是最終一致性以後,同時也明確了我們實現分散式事務的原則,也是最終一致性。

其實,不管是資料庫事務的ACID特性,還是分散式事務的最終一致性,其實,都是根據事務的定義和它的兩個目標,所採取的不同的實現方式。

那麼我們應該怎麼實現這個最終一致性呢?

單服務的分散式事務

首先,任何一個分散式系統,總是由一個個的系統組成,也就是一個個的服務,這些服務又可以部署多個。同時,我們的整個系統也需要一定的方式相互作用、相關通信。有時候,我們可以讓一個服務直接調用另一個服務的介面(如果有提供的話);還有時候,我們可以讓兩個服務通過一個MQ之類的消息中間件通信,共同完成一些業務。但是,無論如何,大部分情況下,分散式系統的一個服務總是會訪問多個數據源。最典型的例子就是通過MQ接受一個事件,然後出發一些操作,再把結果發送到另一個隊列里。

對於這種每個服務訪問多個數據源的情況,其實就是一個最簡單的分散式事務的場景。如果大家在網上搜「Spring分散式事務實現」,搜到的結果也都是在說這個場景下的分散式事務實現過程。

要實現這個事務,首先需要對Spring的事物機制有一定了解。對於這種情況,最簡單的就是使用Spring的JTA事務管理。但是,我們知道,JTA事務管理是通過兩階段提交實現的,在很多情況下,它的效率是很低的。因為它在多個數據源修改數據的時候,這些數據一直都處在被鎖的狀態,知道多個數據源的事務都提交完成,才會釋放。

如果不用JTA,Spring也給我們提供了幾種方式,來近似的實現分散式事務(注意這裡說的近似)。例如:

事務同步,也就是提交一個事物的時候,通過Listener等方式通知另一個事務也提交。但是這種情況下,如果第二個事務提交的時候出錯了,第一個事物就無法回滾,因為他已經提交完成了。

鏈式事務,就是將多個事務,包裝在一個鏈式事務管理器當中,在提交事務的時候,一次提交裡面的事務。對於這種實現,也存在上面說的問題。

還有其他的一些方式,就不過多說明。

所以,使用Spring在單服務多數據源的情況下,實現分散式事務,實際上沒辦法完全實現事務的,因為出錯的時候不能保證都會滾。那麼這時候,就需要再通過其他機制來補充。

首先就是重試,也就是在出錯的時候,重試之前的操作。這在有MQ的時候比較常用,因為一般的MQ伺服器,在你讀消息以後,處理的時候如果出錯了,那麼這個讀消息的操作不會被提交。那這個消息就會被重新讀到,重新出發剛才的操作。這時候,我們就需要考慮這個方法的冪等性,保證在重複消息的時候不會重複處理數據。

其次,我們需要自己處理一些錯誤。例如上面的情況,重試幾次以後,一直沒有成功,那麼這時候就需要走失敗邏輯。有時候,我們也可以通過一個定時器來檢查一定時間內沒有完成的失敗操作。

有些情況下,我們還需要考慮其他各種錯誤,如網路錯誤、超時,系統宕機等等。

大家可以試想一下,分散式系統越複雜,它的各種出錯的情況就越多,我們需要考慮的補救措施就越多。那這種修修補補的實現分散式事務的最終一致性的做法,始終不是一個好的辦法。但是,使用Spring解決單服務的分散式系統,始終是分散式事務實現的基礎。我們可以用其他的模式來方便我們解決分散式事務,但是在每個服務當中,我們還是要經常使用事務同步、鏈式事務等,來實現事務。我們用Spring來保證絕大多數情況下的事務問題,而對於特殊的錯誤情況,就採用其他的模式來解決。

分散式事務實現的模式

剛才說了我們用其他模式來覺得分散式事務問題,那麼都有什麼模式呢?

消息驅動(Event Driven)模式

消息驅動模式是,當某個業務請求需要由多個服務參與完成的時候,這些服務之前不直接通信,而是通過一個MQ中間件來通信。比如對於一個訂單支付的請求,接收到支付完成的請求後,通過MQ,通知訂單服務去完成訂單,訂單服務再去通知商品服務去減庫存,再通知物流服務去發起物流流程。

那麼,對於每一個服務來說,都需要先從一個隊列讀取一個消息,完成自己的業務操作,再往另一個隊列發送一個消息,這就需要操作一個數據和一個MQ伺服器。這也就是上面說的單服務的分散式事務實現。對於這種模式而言,我們用事務同步保證在每個服務中,在大部分情況下都能保證事務。即使偶爾出現網路錯誤、系統錯誤等,通過重試就能解決大部分問題。如果重試一直不能解決,那就再處理失敗邏輯。

我們使用這種方式,最重要的,就是對這個消息、和他的處理流程的編排,其次,它也是一種響應式的編程思維。

事件溯源(Event Sourcing)模式

Event Sourcing在上面說的消息驅動的基礎上,進一步提升事件(也就是之前的消息)的地位,讓它成為系統的一等公民。也就是說,怎麼的系統不是基於原先那些實體的,而是基於事件的,一個事件就代表一個業務操作和業務數據狀態的更改。至於業務數據,我們不需要把它保存在資料庫中,即使保存,也只是為了查詢數據方便而保存。

在Event Sourcing模式中,每個服務完成某個邏輯的方式,跟上面說的消息驅動模式差不多,就是對於用戶的每個操作,會產生一個事件(可能多個),這個事件會被某個服務的某個處理方法處理,它也有可能再產生其他的事件,再由其他服務處理,直到完成整個業務流程。但是,它跟消息驅動的最大區別就是,在Event Sourcing的服務里,業務狀態數據不一定要保存在資料庫中,就算保存,出錯了也沒關係,反正它可以根據Event事件重新生成。所以這個地方的事務,我們只需要保證Event保存成功即可。當然,我們需要其他的機制,方便我們能夠重新生成業務數據,而這,一般都是實現Event Sourcing的框架來提供。

TCC(Try-Confirm-Cancel)模式

除了上面說的通過一個中間價關聯不同的服務,在有些分散式系統當中,我們的不同的服務可以直接通信,例如Spring Cloud微服務框架就提供Rest方式訪問別的服務。那麼這時候,就相當於,我的一個服務除了訪問自己的資料庫以外,還要訪問別的服務,這裡的這個服務就可以當做是一個資料庫。我們可能要調用別的服務的某個介面完成一些業務。

在這種情況下,一個服務提供的介面,不可能實現事務,也就是先操作數據,再Commit,如果出錯了再Rollback。但是,我們可以借鑒事務的這種處理思路,來自己提供類似事務的方法,這就是TCC模式。一個事物是通過Do-Commit/Rollback來實現的,在TCC模式中,是通過給每一個服務間調用的操作介面,提供一套Try-Confirm/Cancel介面。

還是舉一個例子,就是用戶下單以後支付完成。支付完成的時候由先訂單服務處理,然後調用商品服務去減庫存。大家用Spring Cloud的話,可能就在商品服務里寫一個介面直接做減庫存的操作,但是在TCC模式下,我們需要3個介面。首先是減庫存的Try介面,在這裡,我們要檢查業務數據的狀態、檢查商品庫存夠不夠,然後做資源的預留,也就是在某個欄位上設置預留的狀態。然後在Confirm介面里,完成庫存減1的操作。在Cancel介面里,把之前預留的欄位重置。

這可能聽著有點繁瑣,感覺可以一次完成的事情,為什麼要分成2步,首先這麼做是為了能夠在出錯的時候正確的重置庫存數據,其次這個預留操作跟Confirm操作是兩個請求,中間可能會有其他並發請求。從理論上說,只要我們在Try介面裡面預留資源的邏輯是正確的,那麼,即使Confirm的時候出錯了,我也可以通過重試Confirm請求來完成

使用資料庫保存事務狀態

這其實不是一種模式,只是一種方式。例如在TCC模式下,在準備調用Confirm介面的時候,目標服務突然宕機了,或者發起請求的服務突然宕機或出錯了,導致這個Confirm請求一直沒有被調用。那麼,在系統恢復以後,我該怎麼完成之前的事務呢?除了上面說的用定時器定期檢查未完成的操作以外(需要能夠通過某種數據狀態判斷業務沒有執行完成後),我們還可以用資料庫來記錄事務的運行狀態。

例如在TCC模式中,每當一個服務A要使用TCC模式調用另一個服務B的時候,服務A將這個TCC的事務狀態寫到資料庫中,根據具體實現,可能是在調用前記錄當前事務的狀態,調用完成再保存該調用的參數和結果狀態,這個事務完成以後(也就是調用完Confirm,或Cancel以後),再更新成完成的狀態。那麼,通過合理的設計,我們就能在各種出錯情況下,保證能繼續完成這個事務,或取消這個事務。

總結

總之,對於分散式事務來說,沒有一個簡單的像本地事物一樣的實現方式,我們總是需要根據分散式系統的設計,根據業務需求,選擇某種方式來保證數據的一致性。而且,在實現分散式事務的過程中,業務流程的設計也至關重要,不管是用TCC、消息驅動、還是EventSourcing。分散式系統的業務流程,實際上就是一個完備的狀態機,這個狀態機是否包含了所有的事件,是否包含了所有的業務路徑,包括正常的、異常的,合理的設計業務流程,才能更好地實現分散式事務。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 千鋒JAVA開發學院 的精彩文章:

大數據演算法:kNN演算法
5個很實用的數組迭代方法

TAG:千鋒JAVA開發學院 |