分布式是如何實現(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)化器不會取這個索引，會導(dǎo)致鎖表的問題。

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

分布式計算是如何控制事務(wù)的？

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

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

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

1.兩階段/三階段提交

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

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

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

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

2.本地方法表

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

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

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

方法

偽代碼如下，以跨行轉(zhuǎn)賬為例。

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

4.交易MQ

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

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

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

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

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

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

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

7.服務(wù)器收到結(jié)果后執(zhí)行相關(guān)操作。

摘要

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