分布式的優點、分布式鎖及分布式事務處理機制


個人博客網:https://wushaopei.github.io/    (你想要這里多有)

1、關於分布式鎖的了解?

原理:控制分布式系統有序的去對共享資源進行操作,通過互斥來保持一致性。

具備的條件:

①分布式環境下,一個方法在同一時間只能被一個機器的一個線程執行

②高可用的獲取鎖和釋放鎖

③高性能的獲取鎖和釋放鎖

④具備可重入特性

⑤具備鎖失效機制,防止死鎖

分布式鎖的三種實現:

A. 基於數據庫實現分布式鎖;

B. 基於緩存(Redis等)實現分布式鎖;

C. 基於Zookeeper實現分布式鎖

 

A.基於數據庫的實現:

在數據庫中創建一個表,表中包含方法名等字段,並在方法名字段上創建唯一索引,想要執行某個方法,就是用這個方法名向表中插入數據,成功插入則獲取鎖,執行完成后刪除對應的行數據釋放鎖

B.基於緩存(Redis等)實現分布式鎖:

推薦: Redis有很高的性能;

       Redis命令對此支持較好,實現起來比較方便

實現:

(1)獲取鎖的時候,使用setnx加鎖,並使用expire 命令為鎖添加一個超時時間,超過該時間則自動釋放鎖,鎖的value值為一個隨機生成的UUID,通過此在釋放鎖的時候進行判斷。

(2)獲取鎖的時候設置一個獲取的超時時間,若超過這個時間就放棄獲取鎖。

(3)釋放鎖的時候,通過UUID判斷是不是該鎖,若是該鎖,就執行delete進行鎖釋放。

C.基於Zookeeper的實現方式

原因: Zookeeper是一個為分布式應用提供一致性服務的開源組件,它內部是一個分層的文件系統目錄樹結構,規定同一個目錄下只能有一個唯一文件名。

實現:

  1. 創建一個目錄mylock
  2. 線程A想獲取鎖就在mylock目錄下創建臨時順序節點
  3. 獲取mylock目錄下所有的子節點,然后獲取比自己小的兄弟節點,如果不存在,則說明當前線程順序號最小,獲得鎖;
  4. 線程B獲取所有節點,判斷自己是不是最小的節點,設置監聽比自己次小的節點
  5. 線程A處理完,刪除自己的節點,線程B監聽到便跟事件,判斷自己是不是最小的節點,如果是則獲得鎖。
  6. 使用Apache的開源庫Curator,它是一個Zookeeper客戶端,Curator提供的InterProcessMutex是分布式鎖的實現,acquire方法用於獲取鎖,release方法用於釋放鎖。

 

2、 分布式事務處理機制

在CAP定理中,一致性、可用性、分區容錯性是不可能同時存在的。但在實際的應用場景中,數據的一致性是需要保證的。

事務是達到以上目的的最好方法:

即保證執行結果的正確性;保證數據的一致性;ACID

常見的事務處理機制:

Master-Slave 復制:

Slave一般是Master的備份。讀寫都在Master上,異步同步數據到Slave;Master掛了,Slave只能讀。

Master-Master多主復制:

2個以上Master,都提供讀寫服務。一台掛了,另一台正常讀寫。

 

兩階段提交:

第一階段:准備階段:

協調者節點向所有參與者節點詢問是否可以執行提交操作,並開始等待各參與者節點的響應。參與者節點執行詢問發起為止的所有事務操作,並將Undo信息和Redo信息寫入日志。各參與者節點響應協調者節點發起的詢問。

第二階段:提交階段:

如果協調者收到了參與者的失敗消息或者超市直接給每個參與者發送回滾(Rollback)消息;否則,發送提交(Commit)消息;參與者根據協調者的指令執行提交或者回滾操作,釋放所有事務處理過程中使用的鎖資源。

三階段提交:

CanCommit階段:協調者向參與者發送commit請求,參與者如果可以提交就返回Yes響應,否則返回No響應。

PreCommit階段:協調者根據參與者的反應情況來決定是否可以記憶事務的PreCommit操作。

doCommit階段:進行真正的事務提交。具體為執行提交、終端事務。

3、用分布式和沒有用分布式的項目的差異是什么?

  • 傳統項目:

  存在問題:

1:模塊之間耦合度太高,其中一個功能升級,其他的模塊都得一起升級部署。

2:開發困難,各個團隊開發最后都要整合在一起.

3:系統擴展性差

4:不能靈活進行分布式部署

  解決方案:

  把模塊才分成獨立的工程,單節點運行,如果某一個節點壓力大了可以單獨對這個節點進行增加配置,其他節點不受影響。缺點就是系統之間交互需要額外的工作量來進行接口的開發。把系統拆分成多個工程,需要完成系統的工程需要多個工程協作完成,這種形式就叫做分布式。

  • 分布式:

  把系統拆分成多個子系統.

優點:

1:把模塊拆分,使用接口通信,降低模塊之間的耦合度.

2:把項目拆分成若干個子項目,不同的團隊負責不同的子項目.

3:增加功能時只需要再增加一個子項目,調用其他系統的接口就可以。

4:可以靈活的進行分布式部署.

5:提高代碼的復用性,比如service層,如果不采用分布式rest服務方式架構就會在手機wap商城,微信商城,pc,android,ios每個端都要寫一個service層邏輯,開發量大,難以維護一起升級,這時候就可以采用分布式rest服務方式,公用一個service層。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM