分布式鎖+分布式事務(wù)面試題

什么是分布式鎖?

在分布式系統(tǒng)之間，保證某些系統(tǒng)資源同步訪問(wèn)的一種方式。如: 減庫(kù)存的接口 多應(yīng)用訪問(wèn)時(shí)都要對(duì)庫(kù)存數(shù)據(jù)做操作，可能會(huì)造成超賣問(wèn)題可以通過(guò)分布式鎖解決。

分布式鎖的使用場(chǎng)景?

庫(kù)存操作 積分操作 錢包操作

能否基于JDK提供的鎖實(shí)現(xiàn)分布式鎖?

JVM鎖無(wú)法解決: 因?yàn)閷?duì)應(yīng)的服務(wù)會(huì)做集群

分布式鎖有哪些實(shí)現(xiàn)方式?

? 基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)

可以通過(guò)數(shù)據(jù)庫(kù)的悲觀鎖 (行鎖)實(shí)現(xiàn), 在查詢庫(kù)存數(shù)量用于修改時(shí)，在select語(yǔ)句后加上 for update其它客戶端訪問(wèn)時(shí)，如果當(dāng)前庫(kù)存有客戶端在操作,會(huì)產(chǎn)生阻塞。性能低

? 基于Redis實(shí)現(xiàn)

基于Redis的單線程模型， 不同的客戶端并發(fā)操作數(shù)據(jù)時(shí) 通過(guò)redis 的setnx方案嘗試誰(shuí)能在redis中存儲(chǔ)數(shù)據(jù)，能存儲(chǔ)代表獲取到鎖， 當(dāng)操作完畢后再刪除掉對(duì)應(yīng)的keysetnx key value 存在:0 不存在: 設(shè)置成功 并返回1Redission框架實(shí)現(xiàn)了 基于Redis的高可用分布式鎖RLock

? 基于zookeeper實(shí)現(xiàn)

基于zookeeper的文件系統(tǒng)和watch監(jiān)聽(tīng)機(jī)制實(shí)現(xiàn)分布式鎖, 大概實(shí)現(xiàn)思路: 多個(gè)客戶端要操作資源時(shí)，在指定目錄節(jié)點(diǎn)下 創(chuàng)建臨時(shí)節(jié)點(diǎn)， 節(jié)點(diǎn)序號(hào)最小的算占有鎖，當(dāng)執(zhí)行完畢后刪除對(duì)應(yīng)節(jié)點(diǎn)，下一個(gè)最小的節(jié)點(diǎn)占有鎖。

分布式鎖實(shí)現(xiàn)方案對(duì)比總結(jié)?

基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)，最簡(jiǎn)單，性能不好，并發(fā)量少時(shí)可用基于Redis的Redission方案是主推方案，實(shí)現(xiàn)了公平鎖、可重入鎖、支持redis集群、鎖的自動(dòng)續(xù)約，通過(guò)簡(jiǎn)單的配置 ，獲取RLock對(duì)象， 調(diào)用對(duì)象.lock()加鎖 調(diào)用.unlock方法解鎖即可 代碼侵占非常低我們項(xiàng)目中使用的是Redission, 不過(guò)在redis master節(jié)點(diǎn)宕機(jī)后，有多個(gè)客戶端獲取到同一個(gè)鎖的風(fēng)險(xiǎn)。基于zookeeper性能對(duì)比redis稍慢一些，強(qiáng)一致性的zk 在leader宕機(jī)后會(huì)出現(xiàn)短時(shí)間的不可用。

Redission實(shí)現(xiàn)分布式鎖RLock的原理?

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

ZK如何實(shí)現(xiàn)分布式鎖簡(jiǎn)述?

方案一: 創(chuàng)建臨時(shí)節(jié)點(diǎn)實(shí)現(xiàn)分布式鎖客戶端嘗試創(chuàng)建指定文件節(jié)點(diǎn),創(chuàng)建成功占有鎖，沒(méi)創(chuàng)建成功監(jiān)聽(tīng)文件節(jié)點(diǎn)變化，如果文件節(jié)點(diǎn)刪除 再次嘗試 創(chuàng)建指定文件節(jié)點(diǎn) . 成功占有鎖后，如果執(zhí)行完畢代碼 刪除掉對(duì)應(yīng)文件節(jié)點(diǎn)代表釋放鎖。 這種方式會(huì)存在驚群效應(yīng)，當(dāng)多個(gè)客戶端等待鎖釋放時(shí)，如果鎖釋放多個(gè)客戶端會(huì)同時(shí)嘗試創(chuàng)建文件節(jié)點(diǎn)，給zk帶來(lái)很大并發(fā)壓力，性能不好方案二: 創(chuàng)建臨時(shí)順序節(jié)點(diǎn)實(shí)現(xiàn)分布式鎖客戶端嘗試在指定文件節(jié)點(diǎn)目錄下，創(chuàng)建臨時(shí)有序文件節(jié)點(diǎn)， 每個(gè)節(jié)點(diǎn)都有編號(hào)，當(dāng)前編號(hào)最小的文件節(jié)點(diǎn) 為獲取到鎖，執(zhí)行代碼。 每個(gè)等待鎖的客戶端 都監(jiān)聽(tīng)它上一個(gè)節(jié)點(diǎn)的變化。 如果上一個(gè)節(jié)點(diǎn)被刪除了 當(dāng)前節(jié)點(diǎn)編號(hào) 變?yōu)樽钚? 相當(dāng)于獲取到鎖

什么是事務(wù)及事務(wù)的特性?

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

什么是分布式事務(wù)?

在分布式架構(gòu)中，一個(gè)操作可能橫跨多個(gè)微服務(wù)，多個(gè)數(shù)據(jù)庫(kù)，傳統(tǒng)的本地事務(wù)無(wú)法解決，需要使用分布式事務(wù)來(lái)解決。

什么是CAP定理?

在分布式系統(tǒng)中， C： 指的是多個(gè)系統(tǒng)中數(shù)據(jù)的一致性。 A： 指的是服務(wù)的高可用 P： 指的是分區(qū)容錯(cuò)即使網(wǎng)絡(luò)故障的時(shí)候能夠做到分區(qū)容錯(cuò)，在服務(wù)出現(xiàn)癱瘓時(shí)也能保證對(duì)應(yīng)服務(wù)的高可用，而且整個(gè)系統(tǒng)的數(shù)據(jù)保持一致性。想完全滿足以上3點(diǎn)是不可能的，所以業(yè)界主要選擇3保2 優(yōu)先保證兩點(diǎn)，但分區(qū)容錯(cuò)和網(wǎng)絡(luò)有關(guān)無(wú)法避免，所以P必須要保證 常見(jiàn)的兩種方案: CP: 保證一致性,分區(qū)容錯(cuò) AP：保證高可用,分區(qū)容錯(cuò)

什么是Base定理?

Base定理，對(duì)CAP的平衡落地理論。 強(qiáng)調(diào)的是: 保證基本可用(核心服務(wù)高可用)允許存在軟狀態(tài)(運(yùn)行出現(xiàn)一段時(shí)間的數(shù)據(jù)不一致情況)最終一致性(最終能夠達(dá)到數(shù)據(jù)的一致性)

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

zk: cp 強(qiáng)調(diào)一致性eureka: ap 強(qiáng)調(diào)高可用

分布式事務(wù)的解決方案?

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

seata介紹

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

我們項(xiàng)目中分布式事務(wù)是如何處理的?

可以說(shuō)使用seata框架， 不過(guò)最好在0.9以前版本 2019.10.16日發(fā)布0.9版本MQ+本地消息表的方式在過(guò)去使用的最多,因?yàn)榭煽肯㈥?duì)列的異步通信效率很高。 不過(guò)需要針對(duì)特定的場(chǎng)景要做對(duì)應(yīng)的設(shè)計(jì)，當(dāng)子事務(wù)比較多時(shí)，或者要考慮各種補(bǔ)償方案時(shí)實(shí)現(xiàn)比較復(fù)雜。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。