天天看點

分布式事務

分布式事務

什麼是事務

舉個生活中的例子:你去商店買東西就是一個事務的例子,買東西是一個交易,包含“一手交錢,一手交貨”兩個動作,交錢和交貨這兩個動作必須全部成功,交易才算成功,其中任何一個動作失敗,交易就必須撤銷

事務可以看做是一次大的活動,它由不同的小活動組成,這些小活動要麼全部成功,要麼全部失敗

本地事務

在軟體系統中,通常由關系型資料庫來控制事務,這是利用資料庫本身的事務特性來實作的,是以叫資料庫事務,由于應用主要靠關系資料庫來控制事務,而資料庫通常和應用在同一個伺服器,是以基于關系型資料庫的事務又被稱為本地事務

資料庫事務的四大特性 ACID

A(Atomic):原子性,構成事務的所有操作,要麼都執行成功,要麼全部不執行,不可能出現部分成功部分失敗的情況

C(Consistency):一緻性,在事務執行前後,資料庫的一緻性限制沒有被破壞。比如:張三向李四轉100元,轉賬前和轉賬後的資料是正确狀态這叫一緻性,如果出現張三轉出100元,李四賬戶沒有增加100元這就出現了資料錯誤,就沒有達到一緻性

I(Isolation):隔離性,資料庫中的事務一般都是并發的,隔離性是指并發的兩個事務的執行互不幹擾,一個事務不能看到其他事務運作過程的中間狀态。通過配置事務隔離級别可以避髒讀、重複讀等問題

D(Durability):持久性,事務完成之後,該事務對資料的更改會被持久化到資料庫,且不會被復原

資料庫事務在實作時會将一次事務涉及的所有操作全部納入到一個不可分割的執行單元,該執行單元中的所有操作要麼都成功,要麼都失敗,隻要其中任一操作執行失敗,都将導緻整個事務的復原

随着網際網路的快速發展,軟體系統由原來的單體應用轉變為分布式應用,下圖描述了單體應用向分布式微服務應用的演變:

分布式事務

分布式系統會把一個應用系統拆分為可獨立部署的多個服務,是以需要服務與服務之間遠端協作才能完成事務操作,這種分布式系統環境下的事務機制稱之為分布式事務

在分布式架構的基礎上,傳統資料庫事務就無法使用了

比如,張三和李四的賬戶不在一個資料庫中甚至不在一個應用系統裡,怎麼實作轉賬事務?也就是說同樣一個功能,原來是由一個系統完成 的,即使這個功能包含很多個操作,也可以采用資料庫事務(本地事務)搞定,而現在這個功能中包含的 多個操作可能是由多個系統(微服務)參與完成的,此時資料庫事務(本地事務)就無能為力了,這就需要新的分布式事務理論來支撐

CAP理論

CAP是 Consistency、Availiability、Partition tolerance三個詞語的縮寫,分别表示一緻性、可用性、分區容忍性。為了友善對CAP理論的了解,我們結合電商平台中的一些業務場景來了解CAP

我們知道每台資料庫伺服器有他的最大連接配接數、負載和吞吐量,若有一天無法再滿足我們的業務需求,就需要橫向去擴充幾台 Slave(從資料庫) 去分擔 Master(主資料庫) 的壓力

如果服務對資料庫的需求是 IO 密集型的,那可能會經常遇到增删改影響到了查詢效率。這就需要進行讀寫分離,由主資料庫應付增删改操作,由從資料庫應付查詢操作,主從資料庫的資料要進行同步

分布式事務

執行流程

商品服務請求主資料庫寫入商品資訊(添加商品、修改商品、删除商品)

主資料庫向商品服務響應寫入成功

商品服務請求從資料庫讀取商品資訊

CAP介紹

C - Consistency

一緻性是指寫操作後的讀操作可以讀取到最新的資料狀态,當資料分布在多個節點上,從任意節點讀取到的資料都是最新的狀态

商品資訊的讀寫要滿足一緻性就是要實作如下目标

商品服務寫入主資料庫成功,則向從資料庫查詢新資料也成功

商品服務寫入主資料庫失敗,則向從資料庫查詢新資料也失敗

A - Availability

可用性是指任何事務操作都可以得到響應結果,且不會出現響應逾時或響應錯誤

商品資訊讀取滿足可用性就是要實作如下目标

從資料庫接收到資料查詢的請求則立即能夠響應資料查詢結果

從資料庫不允許出現響應逾時或響應錯誤

為了保證可用性,一般需要通過增加從資料庫節點來實作

P - Partition tolerance

通常分布式系統的各個節點部署在不同的子網,這就是網絡分區,不可避免的會出現由于網絡故障而導緻節點之間通信失敗。分布式系統在遇到某節點或網絡分區故障的時候,仍然能夠對外提供滿足一緻性 和可用性的服務,這就是分區容忍性。分布式系統中有某一個或者幾個機器宕掉了,其他剩下的機器還 能夠正常運轉滿足系統需求,或者是機器之間有網絡異常,将分布式系統分隔未獨立的幾個部分,各個部分還能維持分布式系統的運作,這樣就具有較好的分區容忍性

商品資訊讀寫滿足分區容忍性就是要實作如下目标

主資料庫向從資料庫同步資料失敗不影響讀寫操作

其中一個節點挂掉不影響另一個節點對外提供服務

CAP**組合方式**

在所有分布式事務場景中不會同時具備CAP三個特性,因為在具備了P的前提下C和A是不能共存的

在保證分區容忍性的前提下,一緻性和可用性無法兼顧,如果要提高系統的可用性就要增加多個節點,如果要保證資料的一緻性就要實作每個節點的資料一緻,節點越多可用性越好,但是資料一緻性會越差

AP

放棄一緻性,追求分區容忍性和可用性。這是很多分布式系統設計時的選擇

CP

放棄可用性,追求一緻性和分區容錯性,我們的zookeeper其實就是追求的強一緻,又比如跨行轉賬,一次轉賬請求要等待雙方銀行系統都完成整個事務才算完成

CA

放棄分區容忍性,即不進行分區,不考慮由于網絡不通或節點挂掉的問題,則可以實作一緻性和可用性。那麼系統将不是一個标準的分布式系統,我們最常用的關系型資料庫就滿足了CA

總結

CAP是一個已經被證明的理論:一個分布式系統最多隻能同時滿足一緻性(Consistency)、可用性(Availability)和分區容忍性(Partition tolerance)這三 項中的兩項。它可以作為我們進行架構設計、技術選型的考量标準。對于多數大型網際網路應用的場景, 節點衆多、部署分散,而且現在的叢集規模越來越大,是以節點故障、網絡故障是常态,而且要保證服務可用性達到N個9(99.99..%),并要達到良好的響應性能來提高使用者體驗,是以一般都會做出如下選擇:保證P和A,舍棄C強一緻,保證最終一緻性