小編給大家分享一下redis中分布式鎖是不是樂(lè)觀鎖，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專(zhuān)注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶(hù)創(chuàng)新互聯(lián)還提供了醴陵免費(fèi)建站歡迎大家使用！

 簡(jiǎn)單來(lái)說(shuō)，Redis使用樂(lè)觀鎖，相對(duì)于悲觀鎖，在實(shí)現(xiàn)中更加簡(jiǎn)單，在某些場(chǎng)景中的性能也更好。Redis作為一個(gè)輕量級(jí)的、快速的緩存引擎，而不是一個(gè)全功能的關(guān)系型數(shù)據(jù)庫(kù)，既沒(méi)有使用悲觀鎖的必要，也難以承受使用悲觀鎖的成本。

樂(lè)觀鎖（Optimistic Lock），顧名思義，就是很樂(lè)觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，但是在更新的時(shí)候回判斷一下再次期間別人有沒(méi)有去更新這個(gè)數(shù)據(jù)，可以使用版本號(hào)等機(jī)制。樂(lè)觀鎖適用于多讀的應(yīng)用類(lèi)型，這樣可以提高吞吐量。

樂(lè)觀鎖策略：提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新

Redis對(duì)于事務(wù)只提供了非常有限的支持，其實(shí)更多地是試圖繞過(guò)問(wèn)題。

首先，Redis對(duì)于同一事務(wù)中的一組操作，而不是立即執(zhí)行，而是放入一個(gè)queue中，當(dāng)執(zhí)行到EXEC時(shí)，再一起執(zhí)行。事務(wù)執(zhí)行是全局獨(dú)占的，也就是同一時(shí)間只有一個(gè)事務(wù)被執(zhí)行，中途不能被其它事務(wù)打斷。Redis用這種最簡(jiǎn)單的、也是性能最差的方式避免了race condition。

其次，在Redis的事務(wù)中，如果有一個(gè)或多個(gè)操作失敗，其它操作仍然會(huì)成功，也就是說(shuō)它根本沒(méi)有回滾機(jī)制。

這種方式會(huì)帶來(lái)很多嚴(yán)重的問(wèn)題，其中之一是，無(wú)法先讀取某個(gè)數(shù)值后再進(jìn)行依賴(lài)這個(gè)值的操作，因?yàn)榉旁谝粋€(gè)事務(wù)里會(huì)被在同一個(gè)瞬間執(zhí)行，不放在同一個(gè)事務(wù)里又會(huì)導(dǎo)致race condition。解決方法是使用WATCH，它會(huì)監(jiān)視一個(gè)或多個(gè)變量，如果變量的值在調(diào)用WATCH以后和事務(wù)提交之前被別的事務(wù)修改過(guò)了，整個(gè)事務(wù)都會(huì)失敗。這類(lèi)似于操作系統(tǒng)中的CAS（Compare and Set）。我不知道WATCH具體是怎么實(shí)現(xiàn)的，但是我推測(cè)它監(jiān)控了指定變量的版本號(hào)。

即使有了WATCH，Redis的事務(wù)也是受到嚴(yán)重限制的。第一，它沒(méi)有實(shí)現(xiàn)讀數(shù)據(jù)時(shí)的一致性，因?yàn)閃ATCH對(duì)于讀操作不起作用。第二，它不支持回滾。第三，在對(duì)同一變量存在大量并發(fā)寫(xiě)操作時(shí)，性能會(huì)非常差，因?yàn)槊看翁峤皇聞?wù)時(shí)，WATCH監(jiān)控的變量都已經(jīng)被修改了，導(dǎo)致事務(wù)將多次提交失敗。但是，Redis本來(lái)就是一個(gè)KV類(lèi)型的緩存引擎，要處理的是大量讀少量寫(xiě)的場(chǎng)景，對(duì)一致性也沒(méi)有要求。

看完了這篇文章，相信你對(duì)redis中分布式鎖是不是樂(lè)觀鎖有了一定的了解，想了解更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！