分布式事務最終一致性的簡單案例 分布式是如何實現(xiàn)的？

分布式是如何實現(xiàn)的？實現(xiàn)分布式鎖的三種1.基于數(shù)據(jù)庫實現(xiàn)分布式鎖；2.實現(xiàn)基于緩存的分布式鎖(Redis等。);3.基于Zookeeper實現(xiàn)分布式鎖：基于數(shù)據(jù)庫的分布式鎖的實現(xiàn)1.悲觀鎖定使用sel

分布式是如何實現(xiàn)的？

實現(xiàn)分布式鎖的三種

1.基于數(shù)據(jù)庫實現(xiàn)分布式鎖；

2.實現(xiàn)基于緩存的分布式鎖(Redis等。);

3.基于Zookeeper實現(xiàn)分布式鎖：基于數(shù)據(jù)庫的分布式鎖的實現(xiàn)

1.悲觀鎖定使用select … where …進行更新。exclusive locks注意到，:的其他附加功能與第一個功能的實現(xiàn)基本一致。這里需要注意的是 "其中名稱鎖定 "，并且必須對名稱字段進行索引，否則該表將被鎖定。在某些情況下，比如表不大，mysql優(yōu)化器不會取這個索引，會導致鎖表的問題。

2.樂觀鎖和所謂的樂觀鎖和前面的是基于CAS思想，并不互斥，也不會造成鎖等待和消耗資源。在操作過程中，認為沒有并發(fā)，只有upd。

分布式計算是如何控制事務的？

分布式事務:指涉及操作多個數(shù)據(jù)庫的事務。事實上，同一個庫中的事務的概念被擴展到多個庫中的事務。目的是確保分布式系統(tǒng)中的數(shù)據(jù)一致性。分布式事務處理的關鍵是必須有一種方法可以隨時隨地知道事務的所有動作，事務提交或回滾的決策必須產(chǎn)生統(tǒng)一的結果(全部提交或全部回滾)。

X/Open組織(現(xiàn)在的Open Group)定義了分布式事務處理模型。X/Open DTP model (1994)包括應用程序(AP)、事務管理器(TM)、資源管理器(RM)和通信資源管理器(CRM)四個部分。通常，公共事務管理器(TM)是事務中間件，公共資源管理器(RM)是數(shù)據(jù)庫，公共通信資源管理器(CRM)是消息中間件。XA是X/Open DTP定義的交易中間件與數(shù)據(jù)庫之間的接口規(guī)范(即接口函數(shù))，交易中間件用它來通知數(shù)據(jù)庫交易的開始和結束，以及提交和回滾。XA接口函數(shù)由數(shù)據(jù)庫廠商提供。二階提交協(xié)議和三階提交協(xié)議都是從這個思路衍生出來的?？梢哉f，兩階段提交實際上是實現(xiàn)XA分布式事務的關鍵(確切地說，兩階段提交主要是保證分布式事務的原子性，即所有節(jié)點要么做，要么根本不做)。

因此，大多數(shù)關系數(shù)據(jù)庫通過兩階段提交2pc算法完成分布式事務也就不足為奇了。

1.兩階段/三階段提交

2PC/3PC的全稱是: two/three phase commit，中文名是two-phase/three phase submission；為了使所有基于分布式系統(tǒng)架構的節(jié)點進步一個在線路事務處理過程中可以用ACID特性設計的算法，需要引入一個組件作為協(xié)調(diào)器，統(tǒng)一控制所有節(jié)點(稱為參與者)的操作結果，并最終分兩個階段指示這些節(jié)點是否應該真正提交操作結果。算法如下:

第一階段:提交階段(投票階段)

第二階段:執(zhí)行交易提交(執(zhí)行階段)

這種有很多缺點，在復雜場景下通常不推薦使用，除非是非常簡單的場景，非常容易提供回滾，依賴的服務非常少。

2.本地方法表

這種實現(xiàn)的想法其實來自于ebay。其基本設計思想是將遠程分布式事務分解成一系列本地事務。如果不考慮性能和優(yōu)雅的設計，可以借助關系數(shù)據(jù)庫中的表來實現(xiàn)。舉一個跨行轉賬的經(jīng)典例子來描述一下。

第一步偽代碼如下:扣除1W，保證憑證消息通過本地事務插入消息表。

第二步，通知對方銀行賬戶已經(jīng)加了1W。如何通知對方:可以通過輪詢，也可以通過MQ。

方法

偽代碼如下，以跨行轉賬為例。

嘗試{1。在本地更新數(shù)據(jù)庫。如果更新成功，執(zhí)行第二部分。2.通過MQ }catch{rollback()}發(fā)送消息如果第一步失敗，消息將不會發(fā)送到MQ。如果第一步成功，第二步失敗，則捕獲異常回滾數(shù)據(jù)，保證數(shù)據(jù)一致性。

4.交易MQ

有些MQ直接支持分布式交易，比如阿里 s RocketMQ；RocketMQ處理事務消息的一般過程如下:

1.生產(chǎn)者發(fā)送待確認的信息；

保存收到的消息，成功后將狀態(tài)返回給生產(chǎn)者；

3.如果生產(chǎn)者收到的返回是SEND_OK狀態(tài)，則執(zhí)行本地事務操作；

4.根據(jù)本地事務執(zhí)行的結果，生產(chǎn)者是執(zhí)行提交還是回滾；；

5.如果生產(chǎn)者未能執(zhí)行第四步中的操作，服務器將在一段固定時間后對處于待確認狀態(tài)的消息發(fā)起回溯請求；

6.生產(chǎn)者收到回溯請求后，返回commit或rollback根據(jù)本地事務的結果，對本地事務進行處理；

7.服務器收到結果后執(zhí)行相關操作。

摘要

可以看出，第一種是保證絕對的一致性，這種在互聯(lián)網(wǎng)行業(yè)很少使用，主要是性能不好；最后四種情況都保證 "最終一致性 "，應用廣泛；另外，分布式事務其實是一個數(shù)據(jù)一致性問題，可以關注CAP理論和Base理論；可以多關注我的相關文章。