深入理解分布式事務

2021-08-28 14:19:45 字數 2239 閱讀 6338

本文**所有權力歸原作者所有。

我在上一期介紹了spring的事務原理(詳情見《深入理解spring事務原理》),spring事務本質是單機下的事務,是由資料庫本身保證的。今天,我將介紹一種比較複雜的事務:分布式事務。

當資料庫單錶一年產生的資料超過1000w,那麼就要考慮分庫分表,具體分庫分表的原理在此不做解釋,以後有空詳細說,簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候,如果乙個操作既訪問01庫,又訪問02庫,而且要保證資料的一致性,那麼就要用到分布式事務。

所謂的soa化,就是業務的服務化。比如原來單機支撐了整個電商**,現在對整個**進行拆解,分離出了訂單中心、使用者中心、庫存中心。對於訂單中心,有專門的資料庫儲存訂單資訊,使用者中心也有專門的資料庫儲存使用者資訊,庫存中心也會有專門的資料庫儲存庫存資訊。這時候如果要同時對訂單和庫存進行操作,那麼就會涉及到訂單資料庫和庫存資料庫,為了保證資料一致性,就需要用到分布式事務。

以上兩種情況表象不同,但是本質相同,都是因為要操作的資料庫變多了!

所謂的原子性就是說,在整個事務中的所有操作,要麼全部完成,要麼全部不做,沒有中間狀態。對於事務在執行中發生錯誤,所有的操作都會被回滾,整個事務就像從沒被執行過一樣。

事務的執行必須保證系統的一致性,就拿轉賬為例,a有500元,b有300元,如果在乙個事務裡a成功轉給b50元,那麼不管併發多少,不管發生什麼,只要事務執行成功了,那麼最後a賬戶一定是450元,b賬戶一定是350元。

所謂的隔離性就是說,事務與事務之間不會互相影響,乙個事務的中間狀態不會被其他事務感知。

所謂的永續性,就是說一單事務完成了,那麼事務對資料所做的變更就完全儲存在了資料庫中,即使發生停電,系統宕機也是如此。

最經典的場景就是支付了,一筆支付,是對買家賬戶進行扣款,同時對賣家賬戶進行加錢,這些操作必須在乙個事務裡執行,要麼全部成功,要麼全部失敗。而對於買家賬戶屬於買家中心,對應的是買家資料庫,而賣家賬戶屬於賣家中心,對應的是賣家資料庫,對不同資料庫的操作必然需要引入分布式事務。

買家在電商平台下單,往往會涉及到兩個動作,乙個是扣庫存,第二個是更新訂單狀態,庫存和訂單一般屬於不同的資料庫,需要使用分布式事務保證資料一致性。

xa是乙個分布式事務協議,由tuxedo提出。xa中大致分為兩部分:事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現,比如oracle、db2這些商業資料庫都實現了xa介面,而事務管理器作為全域性的排程者,負責各個本地資源的提交和回滾。xa實現分布式事務的原理如下:

總的來說,xa協議比較簡單,而且一旦商業資料庫實現了xa協議,使用分布式事務的成本也比較低。但是,xa也有致命的缺點,那就是效能不理想,特別是在交易下單鏈路,往往併發量很高,xa無法滿足高併發場景。xa目前在商業資料庫支援的比較理想,在mysql資料庫中支援的不太理想,mysql的xa實現,沒有記錄prepare階段日誌,主備切換回導致主庫與備庫資料不一致。許多nosql也沒有支援xa,這讓xa的應用場景變得非常狹隘。

所謂的訊息事務就是基於訊息中介軟體的兩階段提交,本質上是對訊息中介軟體的一種特殊利用,它是將本地事務和發訊息放在了乙個分布式事務裡,保證要麼本地操作成功成功並且對外發訊息成功,要麼兩者都失敗,開源的rocketmq就支援這一特性,具體原理如下:

1、a系統向訊息中介軟體傳送一條預備訊息

2、訊息中介軟體儲存預備訊息並返回成功

3、a執行本地事務

4、a傳送提交訊息給訊息中介軟體

通過以上4步完成了乙個訊息事務。對於以上的4個步驟,每個步驟都可能產生錯誤,下面一一分析:

基於訊息中介軟體的兩階段提交往往用在高併發場景下,將乙個分布式事務拆成乙個訊息事務(a系統的本地操作+發訊息)+b系統的本地操作,其中b系統的操作由訊息驅動,只要訊息事務成功,那麼a操作一定成功,訊息也一定發出來了,這時候b會收到訊息去執行本地操作,如果本地操作失敗,訊息會重投,直到b操作成功,這樣就變相地實現了a與b的分布式事務。原理如下:

雖然上面的方案能夠完成a和b的操作,但是a和b並不是嚴格一致的,而是最終一致的,我們在這裡犧牲了一致性,換來了效能的大幅度提公升。當然,這種玩法也是有風險的,如果b一直執行不成功,那麼一致性會被破壞,具體要不要玩,還是得看業務能夠承擔多少風險。

分布式事務,本質上是對多個資料庫的事務進行統一控制,按照控制力度可以分為:不控制、部分控制和完全控制。不控制就是不引入分布式事務,部分控制就是各種變種的兩階段提交,包括上面提到的訊息事務+最終一致性、tcc模式,而完全控制就是完全實現兩階段提交。部分控制的好處是併發量和效能很好,缺點是資料一致性減弱了,完全控制則是犧牲了效能,保障了一致性,具體用哪種方式,最終還是取決於業務場景。作為技術人員,一定不能忘了技術是為業務服務的,不要為了技術而技術,針對不同業務進行技術選型也是一種很重要的能力!

深入理解分布式事務

碼農網 吳極心 當資料庫單錶一年產生的資料超過1000w,那麼就要考慮分庫分表,具體分庫分表的原理在此不做解釋,以後有空詳細說,簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候,如果乙個操作既訪問01庫,又訪問02庫,而且要保證資料的一致性,那麼就要用到分布式事務。所謂的soa化,就是業務的服務...

深入理解分布式事務

當資料庫單錶一年產生的資料超過1000w,那麼就要考慮分庫分表,具體分庫分表的原理在此不做解釋,以後有空詳細說,簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候,如果乙個操作既訪問01庫,又訪問02庫,而且要保證資料的一致性,那麼就要用到分布式事務。所謂的soa化,就是業務的服務化。比如原來單機...

深入理解分布式事務

我在上一期介紹了spring的事務原理 詳情見 深入理解spring事務原理 spring事務 本質是單機下的事務,是由資料庫本身保證的。今天,我將介紹一種比較複雜的事務 分布式事務 當資料庫單錶一年產生的資料超過1000w,那麼就要考慮分庫分表,具體分庫分表的原理在此不做解釋,以後有空詳細說,簡單...