分散式技術中不可或缺的分散式互斥方案
來源:碼農本農
分散式技術中不可或缺的分散式互斥方案
什麼是分散式互斥?
減庫存是一個很常見的例子,假如兩個執行緒同時查到庫存還有10件,同時賣出10件後,去庫存中減10件,這樣就會造成庫存還剩下-10件。這顯然是不合理的,這就需要當一個執行緒操作的時候,另一個執行緒不能操作,這就是排他性資源訪問。
在分散式系統裡,這種排他性的資源訪問方式,叫作分散式互斥,而這種被互斥訪問的共享資源就叫作臨界資源。
我們一起來看下分散式技術中是如何對臨界資源進行互斥訪問的。
霸道總裁:集中式演算法
集中式演算法就是建立一個協調者,任何三方想要訪問臨界資源都要透過協調者,協調者認為你可以訪問,你才可以訪問,否則就不能訪問。
具體操作就是訪問者先訪問協調者,協調者發現現在沒有其他訪問者佔用資源,就給當前訪問者傳送放行訊號,否則就要按照協調者的規則進行下一步動作,包括排隊,自旋等。
這個互斥演算法,就是我們所說的集中式演算法,也可以叫做中央伺服器演算法。之所以這麼稱呼,是因為協調者代表著集中程式或中央伺服器。
一個程式完成一次臨界資源訪問,需要如下幾個流程和訊息互動: 向協調者傳送請求授權資訊,1次訊息互動; 協調者向程式發放授權資訊,1次訊息互動; 程式使用完臨界資源後,向協調者傳送釋放授權,1次訊息互動。 因此,每個程式完成一次臨界資源訪問,需要進行3次訊息互動。
集中式演算法的優點:
直觀、簡單、資訊互動量少、易於實現,並且所有程式只需和協調者通訊,程式之間無需通訊。
集中式演算法的缺點:
一方面,協調者會成為系統的效能瓶頸。 想象一下,如果有100個程式要訪問臨界資源,那麼協調者要處理100*3=300條訊息。也就是說,協調者處理的訊息數量會隨著需要訪問臨界資源的程式數量線性增加。
另一方面,容易引發單點故障問題。協調者故障,會導致所有的程式均無法訪問臨界資源,導致整個系統不可用,因此,在使用集中式演算法的時候,一定要選擇效能好、可靠性高的伺服器來執行協調者。
目前市場上集中式演算法的實現主要透過redis zookeeper 資料庫實現,這些元件對於在應對高可用,高效能方面都有自己的方案。開發者需要根據不同的業務選擇使用哪種方式。
民主協商:分散式演算法
集中式演算法是訪問者訪問資源前徵求協調者的同意,那麼分散式演算法就是訪問者在訪問資源前徵求其他訪問者的同意。
具體操作為當一個程式要訪問臨界資源時,先向系統中的其他程式傳送一條請求訊息,在接收到所有程式返回的同意訊息後,才可以訪問臨界資源。其中,請求訊息需要包含所請求的資源、請求者的ID,以及發起請求的時間。
這就是民主協商法。在分散式領域中,我們稱之為分散式演算法,或者使用組播和邏輯時鐘的演算法。
這個演算法中,一個程式完成一次臨界資源的訪問,需要進行如下的資訊互動:
向其他n-1個程式傳送訪問臨界資源的請求,總共需要n-1次訊息互動; 需要接收到其他n-1個程式回覆的同意訊息,方可訪問資源,總共需要n-1次訊息互動。
可以看出,一個程式要成功訪問臨界資源,至少需要2*(n-1)次訊息互動。假設,現在系統中的n個程式都要訪問臨界資源,則會同時產生2n(n-1)條訊息。在大型系統中使用分散式演算法,訊息數量會隨著需要訪問臨界資源的程式數量呈指數級增加,容易導致高昂的“溝通成本”。
分散式演算法的優點:
分散式演算法根據“先到先得”以及“投票全票透過”的機制,讓每個程式按時間順序公平地訪問資源,簡單粗暴、易於實現。
分散式演算法的缺點:
當系統內需要訪問臨界資源的程式增多時,容易產生“信令風暴”,也就是程式收到的請求完全超過了自己的處理能力,而導致自己正常的業務無法開展。
一旦某一程式發生故障,無法傳送同意訊息,那麼其他程式均處在等待回覆的狀態中,使得整個系統處於停滯狀態,導致整個系統不可用。所以,相對於集中式演算法的協調者故障,分散式演算法的可用性更低。
當然可以透過檢測其他程式是否可用的方式可以解決阻塞停滯問題,但是無疑增加了系統的複雜性。
因此,分散式演算法適合節點數目少且變動不頻繁的系統,且由於每個程式均需通訊互動,因此適合P2P結構的系統。比如,執行在區域網中的分散式檔案系統,具有P2P結構的系統等。
Hadoop是我們非常熟悉的分散式系統,其中的分散式檔案系統HDFS的檔案修改就是一個典型的應用分散式演算法的場景。
處於同一個區域網內的計算機1、2、3中都有同一份檔案的備份資訊,且它們可以相互通訊。這個共享檔案,就是臨界資源。當計算機1想要修改共享的檔案時,需要進行如下操作:
計算機1向計算機2、3傳送檔案修改請求; 計算機2、3發現自己不需要使用資源,因此同意計算機1的請求; 計算機1收到其他所有計算機的同意訊息後,開始修改該檔案; 計算機1修改完成後,向計算機2、3傳送檔案修改完成的訊息,併傳送修改後的檔案資料; 計算機2和3收到計算機1的新檔案資料後,更新本地的備份檔案。
輪值CEO:令牌環演算法
程式訪問臨界資源問題也可按照輪值CEO的思路實現。 如下圖所示,所有程式構成一個環結構,令牌按照順時針(或逆時針)方向在程式之間傳遞,收到令牌的程式有權訪問臨界資源,訪問完成後將令牌傳送到下一個程式;若該程式不需要訪問臨界資源,則直接把令牌傳送給下一個程式。 在分散式領域,這個演算法叫作令牌環演算法,也可以叫作基於環的演算法。為了便於理解與記憶,你完全可以把這個方法形象地理解為輪值CEO法。
令牌環演算法優點:
相對於分散式演算法,令牌環演算法不需要再徵求其他所有訪問者的同意,只需要將令牌傳遞給下一個訪問者即可,這樣通訊壓力相對變小,通訊效率更高。
公平性更好,在一個週期內,每個程式都能訪問到臨街資源。
不存在單點問題,如果某個訪問者故障了,令牌可以直接往下一個訪問者傳遞,故障的訪問者會自動出局。
令牌環演算法缺點:
不管環中的程式是否想要訪問資源,都需要接收並傳遞令牌,所以也會帶來一些無效通訊。假設系統中有100個程式,那麼程式1訪問完資源後,即使其它99個程式不需要訪問,也必須要等令牌在其他99個程式傳遞完後,才能重新訪問資源,這就降低了系統的實時性。
令牌環演算法的公平性高,在改進單點故障後,穩定性也很高,適用於系統規模較小,並且系統中每個程式使用臨界資源的頻率高且使用時間比較短的場景。
本篇介紹了分散式技術中常見的分散式互斥演算法,下一篇我們探討下具體的分散式互斥實現方案-分散式鎖具體實現。
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70024924/viewspace-3003307/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 搞懂分散式技術12:分散式ID生成方案分散式
- 搞懂分散式技術16:淺談分散式鎖的幾種方案分散式
- 分散式互斥的高效容錯解決方案分散式
- 搞懂分散式技術17:淺析分散式事務分散式
- 分散式技術-Zookeeper概述分散式
- 搞懂分散式技術3:初探分散式協調服務zookeeper分散式
- ZooKeeper 分散式鎖 Curator 原始碼 04:分散式訊號量和互斥鎖分散式原始碼
- 分散式中灰度方案實踐分散式
- 分散式賬本技術的闡述分散式
- 分散式賬本技術的應用分散式
- 分散式賬本技術的潛力分散式
- 分散式賬本技術的優勢分散式
- 搞懂分散式技術1:分散式系統的一些基本概念分散式
- 分散式技術“上位”進行時分散式
- 技術分享 | Redis 之分散式鎖Redis分散式
- 分散式鏈路追蹤技術分散式
- 不同體系分散式儲存技術的技術特性分散式
- 分散式快取方案分散式快取
- 聊聊Oracle的分散式資料庫技術Oracle分散式資料庫
- 分散式賬本技術的應用(二)分散式
- 技術分享| 基於 Etcd 的分散式鎖實現原理及方案分散式
- 分散式系統中的分散式鏈路追蹤與分散式呼叫鏈路分散式
- [分散式][分散式鎖]淺談分散式鎖分散式
- 分散式資料庫技術論壇分散式資料庫
- Ceph分散式儲存技術解讀分散式
- 「分散式技術專題」副本機制分散式
- 「分散式技術專題」故障恢復分散式
- 分散式鎖的解決方案分散式
- 分散式鎖的實現方案分散式
- 搞懂分散式技術19:使用RocketMQ事務訊息解決分散式事務分散式MQ
- 分散式系統設計中的併發訪問解決方案 | 得物技術分散式
- 搞懂分散式技術15:快取更新的套路分散式快取
- 搞懂分散式技術13:快取的那些事分散式快取
- 分散式系統2:分散式系統中的時鐘分散式
- 分散式ID設計方案分散式
- 分散式 - 分散式系統的特點分散式
- 技術分享| Etcd如何實現分散式負載均衡及分散式通知與協調分散式負載
- Kubernetes – Google分散式容器技術初體驗Go分散式