redis中分布式鎖是不是樂觀鎖

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

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

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

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

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

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

其次，在Redis的事務(wù)中，如果有一個或多個操作失敗，其它操作仍然會成功，也就是說它根本沒有回滾機制。

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

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

看完了這篇文章，相信你對redis中分布式鎖是不是樂觀鎖有了一定的了解，想了解更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！