分布式鎖+分布式事務面試題

什么是分布式鎖?

在分布式系統之間，保證某些系統資源同步訪問的一種方式。如: 減庫存的接口 多應用訪問時都要對庫存數據做操作，可能會造成超賣問題可以通過分布式鎖解決。

分布式鎖的使用場景?

庫存操作 積分操作 錢包操作

能否基于JDK提供的鎖實現分布式鎖?

JVM鎖無法解決: 因為對應的服務會做集群

分布式鎖有哪些實現方式?

? 基于數據庫實現

可以通過數據庫的悲觀鎖 (行鎖)實現, 在查詢庫存數量用于修改時，在select語句后加上 for update其它客戶端訪問時，如果當前庫存有客戶端在操作,會產生阻塞。性能低

? 基于Redis實現

基于Redis的單線程模型， 不同的客戶端并發操作數據時 通過redis 的setnx方案嘗試誰能在redis中存儲數據，能存儲代表獲取到鎖， 當操作完畢后再刪除掉對應的keysetnx key value 存在:0 不存在: 設置成功 并返回1Redission框架實現了 基于Redis的高可用分布式鎖RLock

? 基于zookeeper實現

基于zookeeper的文件系統和watch監聽機制實現分布式鎖, 大概實現思路: 多個客戶端要操作資源時，在指定目錄節點下 創建臨時節點， 節點序號最小的算占有鎖，當執行完畢后刪除對應節點，下一個最小的節點占有鎖。

分布式鎖實現方案對比總結?

基于數據庫實現，最簡單，性能不好，并發量少時可用基于Redis的Redission方案是主推方案，實現了公平鎖、可重入鎖、支持redis集群、鎖的自動續約，通過簡單的配置 ，獲取RLock對象， 調用對象.lock()加鎖 調用.unlock方法解鎖即可 代碼侵占非常低我們項目中使用的是Redission, 不過在redis master節點宕機后，有多個客戶端獲取到同一個鎖的風險?；趜ookeeper性能對比redis稍慢一些，強一致性的zk 在leader宕機后會出現短時間的不可用。

Redission實現分布式鎖RLock的原理?

加鎖(lock)1. 每一個競爭鎖的客戶端都會有一個唯一編號(UUID:線程ID)2. 加鎖使用lua腳本，保證多個命令的原子性腳本中考慮到了客戶端的互斥考慮到相同客戶端的重入鎖// 鎖的格式 鎖名 客戶端ID 重入鎖次數hset myLock 8743c9c0-0795-4907-87fd-6c719a6b4586:1 1 鎖的自動續約加鎖后會啟動一個watchdog看門狗，是一個后臺線程，會每隔10秒檢查一下，如果客戶端存活且還持有鎖key，會續約鎖的超時時間解鎖(unlock)也是使用lua腳本 進行解鎖腳本先判斷是否有 hexist 鎖名稱 客戶端ID 對應的信息 不包含: 代表沒有獲得對應的鎖,返回鎖的失效時間如果包含: 會對value部分減1 ，在判斷結果是否大于0大于0代表這個重入鎖還沒有完全解開如果不大于0 則刪除鎖 del key

ZK如何實現分布式鎖簡述?

方案一: 創建臨時節點實現分布式鎖客戶端嘗試創建指定文件節點,創建成功占有鎖，沒創建成功監聽文件節點變化，如果文件節點刪除 再次嘗試 創建指定文件節點 . 成功占有鎖后，如果執行完畢代碼 刪除掉對應文件節點代表釋放鎖。 這種方式會存在驚群效應，當多個客戶端等待鎖釋放時，如果鎖釋放多個客戶端會同時嘗試創建文件節點，給zk帶來很大并發壓力，性能不好方案二: 創建臨時順序節點實現分布式鎖客戶端嘗試在指定文件節點目錄下，創建臨時有序文件節點， 每個節點都有編號，當前編號最小的文件節點 為獲取到鎖，執行代碼。 每個等待鎖的客戶端 都監聽它上一個節點的變化。 如果上一個節點被刪除了 當前節點編號 變為最小 相當于獲取到鎖

什么是事務及事務的特性?

事務 指的是一系列的操作，要么全部成功，要么全部失敗。 在數據庫中，指的是一個操作由一些列SQL組成，這些SQL看成一個整體，要么全部成功，要么全部失敗。數據庫中的事務滿足ACID的特性 原子性（Atomicity） 一致性(Consistency) 隔離性(Isolation) 持久性（Durability）

什么是分布式事務?

在分布式架構中，一個操作可能橫跨多個微服務，多個數據庫，傳統的本地事務無法解決，需要使用分布式事務來解決。

什么是CAP定理?

在分布式系統中， C： 指的是多個系統中數據的一致性。 A： 指的是服務的高可用 P： 指的是分區容錯即使網絡故障的時候能夠做到分區容錯，在服務出現癱瘓時也能保證對應服務的高可用，而且整個系統的數據保持一致性。想完全滿足以上3點是不可能的，所以業界主要選擇3保2 優先保證兩點，但分區容錯和網絡有關無法避免，所以P必須要保證 常見的兩種方案: CP: 保證一致性,分區容錯 AP：保證高可用,分區容錯

什么是Base定理?

Base定理，對CAP的平衡落地理論。 強調的是: 保證基本可用(核心服務高可用)允許存在軟狀態(運行出現一段時間的數據不一致情況)最終一致性(最終能夠達到數據的一致性)

zk和eureka的區別?(從CAP的角度分析)

zk: cp 強調一致性eureka: ap 強調高可用

分布式事務的解決方案?

剛性事務解決方案 (CP)基于XA的二階段提交 (Seata)Seata AT (模式) 1. 預提交操作 真正提交 (提交的同時創建回滾日志) 2. 如果1階段全部提交成功 刪除回顧日志如果1階段有一個失敗 會利用回滾日志 進行數據補償(異步)數據庫必須支持事務JDBC 柔性事務解決方案 (Base)TCC (補償型) (Seata) try 嘗試執行 confirm 確認操作 cancel 取消 SAGA （補償型） (Seata) MQ事務消息 （異步通知） RocketMQMQ+本地消息表 (異步通知) 創建訂單 --> 減庫存 回饋確認

seata介紹

阿里推出的一款開源的、一站式的分布式事務解決方案。 提供了TCC、SAGA、AT等模式的解決方案，XA二階段模式也即將推出，適合各類微服務場景。在2019年1月左右開始推出最初版本，目前已經更新到1.2.1版本，由阿里的團隊積極維護，而且社區非常活躍，是目前非常火的分布式事務解決方案

我們項目中分布式事務是如何處理的?

可以說使用seata框架， 不過最好在0.9以前版本 2019.10.16日發布0.9版本MQ+本地消息表的方式在過去使用的最多,因為可靠消息隊列的異步通信效率很高。 不過需要針對特定的場景要做對應的設計，當子事務比較多時，或者要考慮各種補償方案時實現比較復雜。

總結

以上是生活随笔為你收集整理的你不知道的分布式锁+分布式事务面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。