分布式系統解決方案(三) 分布式事務選擇

2021-10-07 09:04:59 字數 2441 閱讀 7237

1、 原子性(atomicity):操作這些指令時,要麼全部執行成功,要麼全部不執行。只要其中乙個指令執行失敗,所有的指令都執行失敗,資料進行回滾,回到執行指令前的資料狀態。

eg:拿轉賬來說,假設使用者a和使用者b兩者的錢加起來一共是20000,那麼不管a和b之間如何轉賬,轉幾次賬,事務結束後兩個使用者的錢相加起來應該還得是20000,這就是事務的一致性。

2、一致性(consistency):事務的執行使資料從乙個狀態轉換為另乙個狀態,但是對於整個資料的完整性保持穩定。

3、隔離性(isolation):隔離性是當多個使用者併發訪問資料庫時,

比如操作同一張表時,資料庫為每乙個使用者開啟的事務,不能被其他事務的操作所干擾,多個併發事務之間要相互隔離。

即要達到這麼一種效果:對於任意兩個併發的事務t1和t2,在事務t1看來,t2要麼在t1開始之前就已經結束,要麼在t1結束之後才開始,這樣每個事務都感覺不到有其他事務在併發地執行。

4、 永續性(durability):當事務正確完成後,它對於資料的改變是永久性的。

eg: 例如我們在使用jdbc運算元據庫時,在提交事務方法後,提示使用者事務操作完成,當我們程式執行完成直到看到提示後,就可以認定事務以及正確提交,即使這時候資料庫出現了問題,也必須要將我們的事務完全執行完成,否則就會造成我們看到提示事務處理完畢,但是資料庫因為故障而沒有執行事務的重大錯誤。

1、如果有事務, 那麼加入事務, 沒有的話新建乙個(預設情況下)

2、容器不為這個方法開啟事務

3、不管是否存在事務,都建立乙個新的事務,原來的掛起,新的執行完畢,繼續執行老的事務

4、必須在乙個已有的事務中執行,否則丟擲異常

5、必須在乙個沒有的事務中執行,否則丟擲異常(與propagation.mandatory相反)

6、如果其他bean呼叫這個方法,在其他bean中宣告事務,那就用事務.如果其他bean沒有宣告事務,那就不用事務.

1) default (預設) 

這是乙個platfromtransactionmanager預設的隔離級別,使用資料庫預設的事務隔離級別。另外四個與jdbc的隔離級別相對應。

2) read_uncommitted (讀未提交) 

這是事務最低的隔離級別,它允許另外乙個事務可以看到這個事務未提交的資料。這種隔離級別會產生髒讀,不可重複讀和幻像讀。 

3) read_committed (讀已提交) 

保證乙個事務修改的資料提交後才能被另外乙個事務讀取,另外乙個事務不能讀取該事務未提交的資料。這種事務隔離級別可以避免髒讀出現,但是可能會出現不可重複讀和幻像讀。 

4) repeatable_read (可重複讀) 

這種事務隔離級別可以防止髒讀、不可重複讀,但是可能出現幻像讀。它除了保證乙個事務不能讀取另乙個事務未提交的資料外,還保證了不可重複讀。

5) serializable(序列化) 

這是花費最高代價但是最可靠的事務隔離級別,事務被處理為順序執行。除了防止髒讀、不可重複讀外,還避免了幻像讀。

1、cap理論:只能cp 或者 ap。可用性和一致性互斥。

2、base理論:

ba:基本可用:出現了不可預知的故障,但還是能用

e:最終一致性,不要求強一致性,不過通過一些業務處理,稍微晚一點達到最終一致性即可!!

1. 第一階段(投票階段):

協調者節點向所有參與者節點詢問是否可以執行提交操作(vote),並開始等待各參與者節點的響應。

參與者節點執行詢問發起為止的所有事務操作,並將undo資訊和redo資訊寫入日誌。

各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功,則它返回乙個」同意」訊息;如果參與者節點的事務操作實際執行失敗,則它返回乙個」中止」訊息。

2. 第二階段(提交執行階段):

當協調者節點從所有參與者節點獲得的相應訊息都為」同意」時:

協調者節點向所有參與者節點發出」正式提交(commit)」的請求。

參與者節點正式完成操作,並釋放在整個事務期間內占用的資源。

參與者節點向協調者節點傳送」完成」訊息。

協調者節點受到所有參與者節點反饋的」完成」訊息後,完成事務。

如果任一參與者節點在第一階段返回的響應訊息為」中止」,或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時:

協調者節點向所有參與者節點發出」回滾操作(rollback)」的請求。

參與者節點利用之前寫入的undo資訊執行回滾,並釋放在整個事務期間內占用的資源。

參與者節點向協調者節點傳送」回滾完成」訊息。

協調者節點受到所有參與者節點反饋的」回滾完成」訊息後,取消事務。

不管最後結果如何,第二階段都會結束當前事務。

分布式事務(二)分布式事務方案

首先這是普通事務 下面是分布式事務 在微服務系統中,每個微服務應用都可能會有自己的資料庫,它們首先需要控制自己的本地事務。一項業務操作可能會呼叫執行多個微服務。如何保證多個服務執行的多個資料庫的操作整體成功或整體失敗?這就是分布式事務要解決的問題。cap 和 base 是對大規模網際網路系統分布式實...

分布式 2分布式事務

分布式 1概述cap和base 分布式 2分布式事務 分布式 3分布式一致性演算法 分布式 4集群 分布式 5服務限流演算法 分布式 6分布式id 分布式 7效能壓測 分布式 8日誌鏈路跟蹤 分布式 9分布式鎖 redis鎖的幾種實現 參考 分布式系統間各種問題 宕機 網路不穩定 本地事務無法滿足需...

分布式事務解決方案

一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性,需要業務系統結合mq訊息中介軟體實現,在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性,分為三個階段tryi...